都只开放 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 信息是存储在独立的加密芯片里的，似乎这个独立芯片对电源要求低也不完全受手机开关机的电源管理，所以手机没电了或者关机了，这个独立芯片依然会继续工作的，刷机后还能用估计也是刷机并不能清空这个芯片里的数据

zookeeper 和 etcd 的核心功能应该是仲裁，加锁当然也可以认为是一种仲裁逻辑，但是吧有点现实经验的都知道，申请仲裁虽然可靠但肯定不会效率高，实际 web 类项目中，估计大部分场景需要分布式锁的估计只是状态同步而不是仲裁

@bigbyto #14 这分析是不是有点理论派了，加锁大多数情况下只是抑制极限情况下的并发异常，实际性能与冲突率和单操作延时有关，而且实现正常的都是对需要操作的资源加锁而不是对服务加锁，这种情况下并不是全局锁，冲突率实际是极低的，好比 mysql 的表锁和行锁，实际分布式锁实际使用都是行锁，冲突率一般极低才是正常的，所以你这个加锁就是串行过于武断了吧

@ClericPy #15 分布式锁无非解决的就是状态一致，相同的结果确实有很多解决方案，但是从工程实现来说，如果有一个延迟和可靠性都很好的分布式锁服务，似乎这个是实现和维护最简单的方案了吧，加锁逻辑毕竟已经在多线程编程中实际实践验证过了

比如你举例减产这事，如果多数人都能有限预测或者获取这个信息，你信不信开盘后必定暴跌，这才是股票期货的难点，收益并不会随你经验或者信息的积累正增长

能问这个问题一看你就不懂股票，好比通货膨胀，人均收入一万，百万叫有钱人，哪天人均收入百万了，百万收入的还敢叫有钱人，大家都能预测对，那谁错呢？所以必定都不对，所以不可能有你说的这种

@julyclyde #12 你说的对，51 确实是太老了，但是对于硬件有兴趣初学者来说 51 的 dataset 应该是很短很简单的了，初学者首先需要了解时钟、寄存器的作用和配置逻辑、地址空间管理分配、你写的代码如何作用于 io 、以及串口这些简单通信协议，而且还有那么多大学教材可用，过时归过时，但是计算机的这些基础眼见时间内应该是不会变的，合适的入门门槛还是很有利于学习进度的，不过似乎楼主想学习的操作系统和编译原理并不需要了解这些

协议定义是一回事，有没有被广泛实现使用就是另一回事了，毕竟理论和工程实现并不是一回事，osi 定义已经是几十年前的事了，当时也并未遇见到网路能发展到如今如此复杂的程度，未被大范围采用实现确实有不合理的地方，算是名存实亡吧

赞同 #2 ，初学者这还是选用毕竟老的但是好多大学课程都会用的 51 系列，或者现在使用量非常广的 stm 系列，硬件不比软件，且不说资料真的太少找起来非常麻烦，更要命的是个型号之间只能说大体相同，你找到的资料还需要对应型号才行，软件系统一般都有初始兼容，硬件几乎就都没这特性，而且好歹软件还能有个日志和错误输出，单片机没弄好之前就是个砖头，硬件权威的应该是各芯片的 dataset ，但是吧没点基础估计你都看不懂

@bambo 也许可以看哪个转哪个呗

@acbot 个人觉得 ipoe 应该算是只定义了实现流程，比如通过 dhcp 协议传递校验信息和管理会话过期，但实际服务端如何做校验、如何实现会话管理和 qos 并没有严格详细规定，这似乎也就是各家运营商在大结构固定但具体实现却又不完全统一的原因，而且吧所以在 openwrt 这样常用路由固件中并没有看到通用实现

静态地址需要 arp 协议接受的，当然不走 arp 知道 mac 地址直接发包也行，不过 ipoe 只是用 dhcp ，最简单的不过是 dhcp 分配再直接做 mac 和 ip 地址绑定就行，dhcp 过期时解绑，这样不需要改动网络协议你自己设置 ip 也是没用的