不过话说你不是做的是 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 不很轻松么，这个的实现有简单，直接集成在网关里也没毫无问题，这显然已经是改造最小集成最简单的方案了

@lmshl #14 那你这分布式锁实现有问题吧，否则按你这么说 mysql 也无法完成超过这个限值了，那怎么搞岂不是都没用了

超不超卖的本来也不难处理吧，想要尽可能可靠从秒杀来说，既然库存非常小否则也不叫秒杀了，那么就应该除了让正常库存进入下单流程外，其他请求的处理过程都尽可能短，最好到达网关就直接返回，你再搞快照搞回滚，那么不是增加了可能出错的点了吧，多一步就多一步出错的点，啥都不用做自然也不可能有任何异常了

@lmshl #4 粗略看下，秒杀的难点本来也不是多快，否则这的人大概率都能写出一个处理 10k 以上 qps 的程序，现实中秒杀麻烦的是除了要处理商品库存订单问题外，还有营销折扣系统、优惠系统、风控系统、配送与地址系统等等，这一系列下来之后会是一个非常长的流程，在各系统负载一致和事务一致处理起来会非常麻烦，从这一点上来说，直接使用带库存数分布式锁直接拦截在所有系统前面才是最容易实现且靠谱的方案，反而是使用队列平滑再反馈结果其实更麻烦

而且还有现实大概率不会出现却又不得不考虑的崩溃恢复问题，队列造成了较长处理链路是清理的复杂性想满足秒杀场景下较短的崩溃恢复时间还是十分难的，使用分布式锁拦截则可以设置较短的等待时间即可，也没有进入下单的业务流程，随着时间超时后就会自然恢复

@vopsoft #10 那有啥用，我说的是一般只一个进程只能用一个核心，7 层代理那就应该和 7 层比，和 4 层比个啥啊，4 层代理一般情况下都是受限于网速来的

不能因为自己的喜好就怀疑质疑现实啊，否则最后你恐怕就该怀疑质疑自己了

nginx 并发一般是单核心的性能，你看这个 F5 提供的数据可是 56 核的，再说 4 层负载均衡本来就不是 7 层负载均衡能比的，而且吧你说的这个 300M 是连接数，而 nginx 的 c10k 是 qps ，这两不是一个东西吧，对应 F5 的是 requests pre second ，连接数这种 nginx 也不止 10k 啊

网页里的话应该只有 webrtc 了，app 的话还可以把其中一台当作服务器

@rqxiao #4 是的，索引应该是只保存索引字段和主键的值，磁盘 IO 会少很多，而且一般来说索引应该会尽可能保存在内存中，这也可以快一点吧

其实就是虽然都需要全表扫，但是你这个不需要查询除索引外的字段，所以直接在索引上统计就行，且不说索引数据量小了很多，而且大概率索引会在内存中，所以快一点很正常，你 SELECT 加个不在索引中的字段触发回表，你就会发现效率差不多了

区分度不高的列上加索引查询效率不明显，这个主要问题是这个字段添加过滤条件后，需要扫描的数据条数几乎和不加索引差距不大，所以并不能明显提高效率，更不要说你这个地方都没有添加任何过滤条件，无论怎么着都要扫描所有数据

@qsmd42 #36 但是真的可以靠卫星兼容手机？毕竟距离和大气层限制可是实实在在的，GPS 这种单向的还可以靠卫星调整方向功率来让手机小功率小天线依然可以接收，那手机发射的怎么办啊，功率不到直接就被大气层吸收完了吧，卫星再牛也不能把天线伸过来吧

看有介绍说发射功率 2w ，专业做卫星电话的设备不说有外部长天线，看好多评测还要尽量导户外并且需要大概对准微信方向，所以大概率随时随地捞出来就能打卫星电话短信什么的估计是想太多了吧，而且这么高发射功率，你这电池能抗几分钟啊，所以平时微信通信肯定是关闭的，使用时才会打开并且需要很长时间的搜星对准估计才能使用，替代上网什么的估计大概率聊胜于无了，再说信号什么的，5G 和卫星通信毫不相干吧

sort 过程中并没有创建新 slice ，那么说明排序过程会交换变量位置，你这个第二个排序过程中 c 和 d 两个 slice 中相同索引位置已经不是最开始相同元素了啊，排序结果当然是不对的，这个很明显的吧