@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 也是没用的

tunnel/udp2raw 和远程服务器之间再挂个 tcp 转发代理

tunnel/udp2raw 前面再挂个代理呗，代理转发的时候就可以支持域名解析了吧，本地只是转发流量的话性能也不会有多大损失

不过话说你不是做的是 https 连接池么，那么不就是要被后续请求继续使用么，那么只要保证后续请求都是同一个域名的，这个本来就没问题的吧，几乎 http 服务端都是支持的吧，并不需要额外实现

数据库不支持保存点吧，比如 mysql 好像就没有保存点支持

但是如果你是想复用 tsl 连接，那么显然可以啊，tls 连接本来和你传输的数据无关，如果你是想复用这个 tcp 连接再重新建立一个 tls 或者传输其他协议的数据，不修改服务端的情况下肯定不能了

如果服务端不能修改的话不能，否则不就是代理么，服务端自己解析不同数据包分别处理

@eviladan0s #6 持续用个几天就出来了，丢包率会慢慢升高，并不是一下子就完全挂了，再说不能用本身也是丢包率过高，当然如果短时间流量过高也会完全断了，但一般都是非常高的丢包率

FPGA 的编程语言和 c 可是完完全全不一样的，习惯了 c 的话估计也很难理解 FPGA 咋回事，或者你可以先搞个板子来先玩一下

@lmshl #17 https://github.com/snower/slock
顺便说我已经做出来了，真的不是在嘴炮，3 节点多机强一致阶段大概能有超过 10 万 qps ，并行阶段能接近 200 万 qps ，极其简单的协议也可以直接集成在 openresty 里，我还是觉得这种在非淘宝拼多多这种超大站点，这个应该是最容易实现维护的架构了，毕竟只要你不是动辄秒大量商品库存，只要在现有订单系统前添加拦截流程就可以，几乎不需要针对秒杀逻辑对订单系统做单独调整

@lmshl #17 网络请求又不是串行的，整个分布式锁本来也就只在加减一才串行，哪里有问题了，就算要多机强一致，网络请求同步过程依然可以并行，多机强一致下百万以上 qps 可能做不到，十几万 qps 也还是可以的，一旦库存抢完就进入完全并行阶段，百万以上 qps 不很轻松么，这个的实现有简单，直接集成在网关里也没毫无问题，这显然已经是改造最小集成最简单的方案了