如果一次性的话，直接小表读出来存到 dict 里，大表顺序读判断就是了啊，16g 内存绰绰有余了，才一千万，又不是一千亿，不用想那么多吧

需要重复做的话，这是结构设计问题，应该在源头来解决吧

@marquina #14 之前测试过 freedns、smartdns、unbound，似乎转发请求时可以的，但是缓存管理都有问题，首次请求之后，我换个 ip 再请求还是刚才的，unbound 支持好一点，如果首次时带 ip 请求，缓存管理似乎就正常了，如果不是那么后面无论带啥 ip 请求都是第一次的结果，坑死。。

支持 edns 缓存不呐？试了好几个 dns 服务，对指定了 client ip 的 dns 缓存都有问题

既然锁是和记录关联的，你都说了这行不存在，那如何给这一行加锁呢，虽然我房子还没建但是你先给我上个锁的意思？？

爬商品也就算了，还敢请求下单支付接口，不怕分分钟进去了么，开发也是有责任的，小心点

牛叉，屏幕共享都能搞出来，酷

@linxy19957 #5 既然能改指针，那么分离读写指针完全就可以不需要拷贝了啊
逻辑地址映射是按页完成的，而且 64 位系统下逻辑地址空间那么大，循环映射，没可能

你是不是想多了，就算能映射，你在程序里使用的不还是逻辑地址，你访问完 0x1000 接着就是 0x1001，难不成就能自动回到 0x0000 了？循环映射？似乎 cpu 就没这功能吧

说来说去，其实简单来说就是在整个 redis 中，最消耗资源的其实是网络数据读取写入、协议解析、数据结构准备，而这些全部都是可以多线程并行化无需加锁的，而最后的真正完成命令操作的部分基于特定的的数据结构和已准备好的数据结构来说并不时很消耗资源，所以多线程解决不是命令真正执行部分很自然

既然如此，为啥不能按 content-type 来解码，前端爱用啥用啥呗，http 都给你定义好了，没必要纠结吧

@zhuawadao #3 微服务的首先要求不就是不能有联表查询么，如果实在有这个需求但又不好解决，那说明你可能是在强行微服务，拆分不合理

微服务拆分可以按单一完整功能拆分也可以按业务拆分，数据流上看对数据库的依赖每个服务应该是内聚管理的，换言之如果尽可能在微服务内部完成数据重组，以及实时计算、离线计算这样来处理关联数据，微服务面向的本来也是超复杂业务、数据量大系统，别功能页面没几个，一个月都没几个人用，还搞啥微服务，那真的是在作死

关于中心节点问题，既然微服务，逻辑拆分上是不应该出现完全中心节点，当然大节点避免不了，那么按照节点重要成都，运维要求、服务治理要求、性能稳定性要求都是不一样的，微服务的特点也在于此，本身就应该随着业务发展不断升级进化，你都发展成超级大车，前面的小马不好好升级一下，不死才见鬼了

@shazhouyouren #12 错，你这样想恐怕还得再学学法律了，法律维护合同有效性并不是无差别的，而是基于现实原则于合同事先约定来维护双方公平正义合理，换句话说，任何合同约定有效比如有一个隐性的前提条件，即合同执行和合同约定时必须无明显现实变化，现在属于疫情紧急封闭管制时期，我们显然没有和自如事先并没有约定自如在这种情况下还应该持续提供无差别服务，那么完全应该基于现实原则秉承公平正义合理重新认证自如应该提供的服务水平，这完全是合理的也完全符合法律精神和法律原则。

再说吧，自如或许因为没有请家政上午服务是省了一点钱，但是在这种疫情紧急情况下，你怎么又知道自如没有做其他事情增加了其他成本了呢？这种时候就下这样决断太不合理了吧，我们是自如用户，在这种紧急情况下，如果说没有为自如共同承担防疫成本无论从法律还是道德层面都说不过去吧。

从道德来说，同情同理心是一个社会文明的标志，我们都是受过良好教育的成年人了，至于么。

不就二月份没上门么，这也属于疫情不可抗力因素，你们至于么，又不是自如有意下调服务标准，说了这么多年顾客是上帝，还真把自己当上帝了，有点同理心必要的时候给予合适理解这是应该的吧，还维权，闹到法院法律也不可能支持

看看谁启动的呗，fpm 启动的那么说明要么你的 PHP 代码被注入了，要么 php-fpm 都被替换了

实现过一个，B1、B2、B3 中间机器开启端口转发，A 通过 B1、B2、B3 建立三条固定到 C 的 TCP 连接，A 通过轮询 B1、B2、B3 方式把所有数据包通过三条 TCP 连接发往 C，C 重新组包排序，A 和 C 之间多路复用实现代理转发请求

@optional #6 队列的问题是抽奖人数无法准确预估，如果预估比实际少，一开始很快抽完了会影响活动效果，预估比实际多，受队列限制无法自适应提高中奖概率，也会影响活动效果

我感觉不需要那么复杂，加锁就是了吧，反正概率算法确定是否中奖这个不需要加锁，所以完全可以先抽中从奖池真正取奖品的时候加锁保证唯一性就好了，抽奖人可能很多，中奖人不可能也很多吧

如果中奖人也很多，那说明你这奖品也不值钱，那就更无所谓了，就算有并发问题，多发个几十几百的这算个毛事，根本无需考虑吧

@lsylsy2 #4 抽奖不是秒杀，假设活动持续三天那么应该是尽可能的匹配人流分布在整个时间段内平均的抽中，否则万一一开始就全抽完了，后面就没法玩了，所以用队列看起来不是很科学吧