买硬盘包装盒，很便宜

挺有意思的故事。因为大多数人都是能力一般的，只有极少数人才是能力超强的，“幸运”这个东西又是按概率出现的，所以能力一般的人成功的概率比能力超强的人要大。

当然他也说了，这个实验是 20-60 岁这 40 年的结论，如果人的寿命足够长，比如 1000 年，“幸运”就会被稀释掉，还是能力为王。

自助洗车每次 10 元搞定，大概 7-10 天去一次，一次 30 分钟，当是锻炼身体了。
1. 喷泡沫（算是预洗吧）
2. 冲水
3. 喷泡沫
4. 毛巾擦车
5. 冲水
6. 擦干水（自己买了个大的收水毛巾，很好用，只用轻轻一带水就吸干了）

locale 和 language 都是系统可修改的吧，无所谓准不准，按用户的设置来。
@loading @Cbdy

@christin 这种只能配对一个的设备，确实麻烦。但是重新配对，是蓝牙协议的安全设计。。。 比如你在电脑上删除了配对信息，但是蓝牙设备里存的还是之前的配对信息，这样就配对不上，需要重新配对。如果是原电脑重新配对，蓝牙可以降低安全性允许设备还用老信息重新配对。如果换电脑的话，那就必须重新配对了。

楼主难道是受到 jsonp 的影响。

好多年前，好像应对跨域的情况有用 jsonp ，直接拿 js 代码执行。。。

全用 post 确实能减少很多沟通成本，请求参数全都用一种固定的 json 格式，这样大家都方便。

get 请求 url 上面携带参数确实会提高一些沟通成本，比如遇到的几个情况：

1. 如果参数是数组，大家要协商用什么形式传递大家都方便处理，不同框架的处理情况可能不一致
2. 如果参数值中有空格或者百分号等会转码的字符，双方的 urldecode 方法和规范要一致

还有几个想不起来了。但是自从全用 post 传递 json ，这些问题都不用沟通了。

楼上很多说先取 id 的，只取 id 的话，是不用 offset 条件了吗？慢的原因不就是 offset 的值太大了，问题不还是存在吗？

当其中有一个协程有错误，另一个协程在密集计算，应该是没法打断直接返回的吧

@vindurriel
@xiaotanyu13

写入单行：在 mysql transaction 的最后一步写 redis 如果写入不成功 db 回滚 redis 不是集群的话就强一致了

================================================================================

先更新 mysql，再更新 redis，如果 redis 更新失败，直接抛异常 让 mysql 回滚

==========================================================

极限情况下，redis 成功，mysql 还没 commit 挂了 - -

@Jrue0011 有可能是的。这种方法，感觉不是后台全场景都那么适用吧，后台一般有各种事务和查询条件。。。如果不是全数据都在 redis 里，在后台查询的时候也挺恶心，热的从 redis 查，冷的从数据库查？

@dawniii 这算是最终一致性？

@sampeng 不管怎么实现，都需要面临双写的情况吧。极限情况可能会出现，其中一个成功，另一个失败。然后再弄个分布式的事务去重试或者回滚（逆操作）吗？但是在你程序回滚的过程中，确实有脏数据了。

@sampeng 总感觉很多极限情况下，会有问题。比如 redis 写成功了，mysql 还没 commit 呢，机器挂了，redis 不会自动回滚吧，这时候 redis 的就是脏数据了，感觉总是要牺牲点什么。

这不是离线任务吗？找个从库，闲时去跑，就算跑的慢了影响大吗？

直接公网 ip 映射出去，有 https 吗？

@dawniii 之前 curl 是 cpu 涨，还不是内存。内存出问题，基本没遇到。可以看看数据统计是统计的真实占用的物理内存，还是带 buffer 的？

第三方扩展是可能存在内存泄露的，之前遇到过 curl 某个版本有问题，升级就好了。

看场景

1.假如是今日签到的按钮，后端肯定要做禁止重复签到的检验。

2.假如是后台发文章的接口，如果后端有标题不能重复的判断，自然也就没法重复提交。

3.假如还是发文章或者评论，并没有什么业务上的字段非重复要求，后端就没必要特殊处理，就算处理也是防止灌水处理吧。

以上所有场景前端肯定应该做按钮 disable 处理的，前两个场景是正常的错误提示，最后一个场景是防止非预期的“灌水”。