@neilp 至少公共场所不丢失

@neilp 尽可能不让偷。。

@hxtheone 把锁做在花鼓里呢？难道他要即时换个花鼓。。

@tsaohai 这个到没有，如果可以真想做了他，太 tm 烦人了

@loading 丢了好多次都是直接在公共场所被人骑走的。。

@upczww 丢了好多次都是在公共场所分分钟开锁骑走了，你说的这种情况毕竟不多见

@SkyLanD 其实现在的锁的弱点还是在锁头，毕竟带个能剪断那么粗的钢索的设备来说大多数情况还是不多见的，特别是公共场所，抬走就更不现实了，而锁头太通用了，很多工具都可以开，而且时间不超过两分钟就能搞定，要是能设计个通过手机控制的锁头，是不是好很多，毕竟以大多数小偷的水平来说应该搞不定

@mdzz 这都行。。牛逼

@mumuy http://www.mca.gov.cn/article/sj/tjbz/a/2016/20160707/2016071014.html

其实中国民政部的网站上给出的似乎才是最新的，国家统计局那边的都好久没更新了

@ZE3kr 微信不是一直使用 https 的么？

或者简单的在有网的时候提前更新一个和账号相关支付密钥也可以啊，然后支付的时候用这个密钥签名或加密都行，总不可能你一直没网吧，有网的时候刷新一下这个密钥就行了

@chenset 看你描述的这个场景我觉得还是第二种比较好

重点是当和用户相关的数据越来越多的时候用户 model 里岂不是越来越多方法，每个细分功能都会修改 user model ，这样不合适吧，除非所有细分功能共用，否则最好还是写到各自 model 里比较好

推荐 https://github.com/snower/TorMySQL 正在用在生产环境中，虽然官方推荐使用同步就可以了，但异步和同步相比也有自己的好处
Peewee 改过异步版本，不过事务上不太好处理，高并发下和同步版本 Peewee 性能差距不大

@Rosanta 恩，确实，虽然 redis 写请求大半，但每秒也不到一千，这小意思了吧

@zeroJason 看需求像是实时统计展示之类的，如果是这样的话 50w 个长连接推送更靠谱吧， 5 秒发 50 万推送还是很简单的，每秒处理 50 万请求就有点太不靠谱了，而且可以数据不变更不推送，这样推送次数明显变少了吧，再者如果数据是类线性变化的话，还可以客户端计时自己加，然后服务端没过一段时间推送正确值修正就可以了，这样推送量有变低了

秒杀？每秒五十万，每天数百亿？这么牛逼恐怕不是简简单单优化就能搞的定的吧

@linoder 写缓存？这就是说用户空间内存使用加写缓存？