一样的啊， logging 底层有锁的啊，线程安全的

其实还是没看懂这个怎么对其的，有人解释一下么？

@fleer 除此之外似乎暂时也没什么其他用途。。

@Strikeactor 原来如此，一下子没想通，对 docker 也还不太熟。。

@Strikeactor 没有 bash ，没有 apt-get ，没有 yum ，没有 rpm ，没有 dpkg 。。研究了半天，终于发现原来它和灵雀云是完全不一样的，他给的不是 docker 系统，是 docker 环境，你可以在这个环境下自己 pull 镜像，自己 run 系统。。

正在 Ping 172.99.79.44 具有 32 字节的数据:
来自 172.99.79.44 的回复: 字节=32 时间=248ms TTL=46
来自 172.99.79.44 的回复: 字节=32 时间=249ms TTL=46
来自 172.99.79.44 的回复: 字节=32 时间=249ms TTL=46
来自 172.99.79.44 的回复: 字节=32 时间=348ms TTL=46

172.99.79.44 的 Ping 统计信息:
数据包: 已发送 = 4 ，已接收 = 4 ，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
最短 = 248ms ，最长 = 348ms ，平均 = 273ms

这是什么系统啊？不会安装软件了。。

@xloger 你如此鄙视南京好么。。。

来南京么？

@baskice 这样数据一致性要疯的， mysql 写入性能也没差到这种地步，还是看写入频次和写入量吧，频次高量大的准确性要求一般来说会低一些，比如浏览次数播放次数，视屏上传，评论之类的哪有那么高的频次和量，但准确性要求就高了很多， mysql 直接写完全没事

@naffan 真正加购物车的不是这两个。。。 ajax 请求里做的，这两个只是加成功的提示页

@naffan 伪静态，数字就是商品 ID ，也就是 skuid ，你可以对京东和淘宝的分别加一下购物车看下参数就知道他们怎么设计的数据结构了，淘宝加购物车有两个 id ，一个是 item_id,另一个是 skuId ，京东则只有一个 pid

看淘宝似乎是相同商品，不同属性，京东则是不同规格不同商品，如果物流自己做又复杂的话，可能不同规格不同商品好一些吧，否则整个流程太复杂了

@yuchting 母机问题，这个倒还没想过，不过所有都试了还是无法解释的话，还真有可能。。
如果 mongodb 傻逼了的话，一般会有什么问题呢？

@MartinWu 看了，处于 waitForLock 状态，每次等的查询不一样
@yuchting ucloud 主机，应该是有 ssd 的吧，而且每秒写只有几十， iotop 看的时候每秒写 60 几 kB 吧，不算什么吧，日志中看很奇怪，针对主键_id 跟新已存在 key 的值也会出现长达 30 秒的，插入也会出现 20 多秒的， mongodb 不应该这么弱啊
@vietor 数据量很低的，总量才一个来 G ，不需要分片吧

@lianghui 没有这样的查询啊，数据最多一个 collection 也才不到一百万，也不可能锁那么久啊
@mengzhuo mongostat 读写， io ， fault 都很低，但就是突然卡一下，突然卡一下的，

@em70 哈哈哈， 233333

@oott123 单页在现在版本已经可以正常使用了，就是必须在 pushState 操作 url 变更后重新签名

@moult 遇到过一次是浏览器自动去掉 url 后边的最后一个&之类的，这时候会出现 location.href 取到的是包含&之类，但微信取到的是不包含的，这时候就会出现签名错误，但你自己取出来校验确实正确的