@leonshaw #20 btc 、eth 这样的公链区块大小和出块时间大概率是固定的，最终会是谁出价高谁能放到区块里吧，而 ipfs 这样就是存储的，经济模型是挺复杂的，你可以自己去查一查，xLog 用的好像也是 ipfs

@qile1 #14 https://support.huaweicloud.com/productdesc-bcs/bcs_productdesc_0013.html

华为就干这个啊，联盟链，区块链不是难点，麻烦的是组联盟节点，搞定数据安全要求以及资质，毕竟国内大概率是公立医院吧，所以搞到最后你大概率发现这事难点和区块链什么的关系不大，麻烦的是要有官方机构承认和担保

@rizon #10 当然不会有那么多人天天开着机器给你当服务器用，人家开着的原因是有收益，发文章是肯定要付钱的

其实小不堵主路堵的，其实堵的时间是固定的，所以现在已经好多都是动态时间的本来就是为了这样的吧，每天不同时间去看红绿灯不同方向时间不固定，还有各种联网的直接远程调度的，其实吧用城市大脑远程规划调度的似乎更未来一些，不过作用也有限，想把堵变成不堵那几乎不可能

破产了属于公司的资产和债务还是它的，并不会消失吧，之前签订的合同也不会作废，但是现在的问题是你没付首付，之前签的合同应该不算有效吧，你有钥匙也没用的吧，如果合同确实没效，那总会有债权人来找你的

unix socket 又不是写到文件再读出来的，哥啊，暴露读书少了

@guguji #9 看其实，我们写业务流程是直接写代码，你写业务流程是写配置，那么你需要一个模板引擎啊，开发配置时写模板，之后用对应的环境信息编译生成对应环境的配置设置到数据库之类的就好吧，模板就可以用 git 管理吧

如果考虑到上线时配置过多，需要学习不容易快速完成，那么应该全部有默认配置，上线后先以默认配置运行，之后按需修改，业务配置的默认参数应该时依据运维环境相关配置动态生成，所以业务配置不会有环境相关不能直接以默认配置运行的情况，运维配置无非是数据地址域名什么的，不大可能需要配置非常多又不能一致的，而且吧设计的时候，默认配置一般是硬编码在代码里的，确实需要存数据库的，要么和正常配置数据分开存要么有独立标识代码里做兼容

总的来说，个人认为 diff 同步一致方案肯定是个坑，感觉不大可能有靠谱的方案的，除非你是配置完就再也不需要改了这种

@xuanbg #1 配置中心才是坑死人的，如果把业务数据也放到配置中心来配置，然后测试开发生产都在一起，你确定不会分分钟搞崩生产环境？

运维、产品、运营、市场不同的配置不同人自己负责呗，为啥要 diff 同步，这种容易坑人，除了运维，其他的配置自身就是产品流程的一部分，功能设计的时候本来就要在产品流程中设计操作功能

你这既要动态配置有要求开发测试生产环境一致，本来就是静态功能，直接硬编码随着迭代正常发布测试就行吧，不需要可配自然也不需要同步，过度设计制造麻烦啊，测试开发应该只负责功能一致，谁负责的配置需求谁负责设置并完成回归测试呗，比如一个运营配置需求，刚上线时还没正式开放功能使用时你不让他自己弄一遍并完成回归测试，后面还不分分钟出事故啊

都只开放 80/443 了，说不定还开着流量分析和上网行为分析，小心被抓啊，看起来老板挺看重这种行为的，别搞出个”大事“来，2333~

@FrankHB 我们现在讨论的是 web 类的无状态服务的状态同步加锁问题，和 gil 本来就不是一回事，和多线程编程也只是类比，并不完全是一回事

@bigbyto #43 是的，mysql 的单行单字段的读写性能大概率比大家想的高多了，我们也是想就我们的电商需求不大可能超过 mysql 的单行读写性能，那么就只需解决并发异常就行了，真到了 mysql 都支撑不了了，我们都起飞了，有了资源还怕啥，哈哈

@bigbyto #41 是的，并没有一刀切的通用方案，每个方案都各有优势，就看自己的需求了，如果允许超卖，redis 计库存也挺好的，我提这个方案只是觉得再大多数企业都不可能有美团淘宝这样的量，加锁是实现最直观并且使用产品需求最多又出异常可能最少的方案了

我们的加锁服务是自己实现的，相同机器上差不多能有 3-5 倍 redis 的 qps ，当然我们用的挺好，也不一定就适合你，开发容易维护简单适合自己需求才是真的

https://github.com/snower/slock

@bigbyto #39 但是事务竞争行锁超过系统限值的问题，无论你用不用分布式锁都是要解决的，我并没有说分布式锁可以同时满足限流逻辑，其解决的仅仅是商品库存校验过程中的并发问题，当然设计合理的分布式锁可以提供限流服务，从系统结构上倒是可以简化有点，我们自己在实现的时候也是充分考虑了我们的流量上限的，而且数据库及其他服务都有连接池限制，超过之后也会 wait ，连接池限制了不可能突破底层数据库和服务的性能限制，所有就直接用使用的异步 IO 框架硬抗了

@bigbyto #35 顺便说，现在不都喜欢用异步 IO 框架么，针对热点商品，因为冲突率上升导致等待时间增长，那么自身就组成了一个虚拟的队列，而且这个队列无状态自恢复高性能，自身就具备很好的削峰填谷的效果，毕竟美团这种就算是热点商品一天估计也就能卖几千几万的，等待时间订单顶多也就是半分钟，还是在 loading 等待期限之内的吧

@bigbyto #35 是的，我们的电商服务就是这么设计的，虽然 qps 不算高，高的时候也就上千，不过使用上一致都是很稳定的，因为加锁逻辑相比乐观锁或者队列串行之类还是直观不少，维护和产品逻辑变更感觉上还是相对比较容易的

热点商品是否能支持的很好，其实这个应该和你服务整体支持的性能容量有关吧，如果你整体服务性能容量不足，你怎么着都无法处理这么多下单请求，这个地方应该时只需要考虑你分布式锁会不会成为整个订单服务的性能不足点就可以了

关于大量的请求都获得了锁把下游的服务击穿，你确定这个不是应该由限流、熔断服务及削峰填谷策略来解决的么，和是否使用分布式锁来处理关系不大吧

@bigbyto #28 比如外卖下单对商品库存加锁这个逻辑吧，我们正常使用分布式锁的逻辑应该对商品 ID 加锁，虽然美团这样的平台每天订单海量，但是商品也是海量的啊，普通场景下对单个商品的瞬间下单请求并会很高吧

对于多个资源那就更简单了，把多个资源的 ID 拼成一个 key 来加锁就行吧，简单来说，我们使用分布式锁是对“{唯一操作类型}+{join(所有该操作设计的资源 ID)}” 这样一个 key 加锁吧

顺便说，在下单这样场景中，下单操作就是唯一操作类型，库存操作才是，资源 ID 自然就是商品 ID ，对商品 ID 的加锁应该只持续了对这个商品校验生成订单的商品信息这一小步，而不是整个下单流程，如果最后又下单失败应该走事务回滚逻辑，而不是让加锁持续整个下单逻辑，否则比如下单时选择的商品顺序不一致你就要死锁了，这样一看，是不是就算时电商下单这样的逻辑上其实冲突率都并不会很高

Aqara 生成的 nfc 虚拟门卡应该是保存了自己的密钥的，nfc 信息里也写了校验密钥，你之间用 iPhone 生成的公交卡，Aqara 既不知道校验密钥不能修改其 nfc 信息加入自己密钥，换言之你的意思是只要是你生成公交卡的 id 刷就可以开门，你说这个有没有安全问题，关于获取你 iPhone 生成的公交卡 id 的事情更简单了啊，只要靠近你手机瞬间就可以复制走了

顺便说手机关机也可以开门这个，手机的 nfc 信息是存储在独立的加密芯片里的，似乎这个独立芯片对电源要求低也不完全受手机开关机的电源管理，所以手机没电了或者关机了，这个独立芯片依然会继续工作的，刷机后还能用估计也是刷机并不能清空这个芯片里的数据