第一种情况需要做 1 主多从，架设负载均衡将 QPS 摊到各台机器

第二种情况数据太多了，内存放不下的，但是如果成本足够的话使用去中心化的 Redis Cluster 处理，其实更好的方案应该是不使用 Redis，内存代价太高了

建议了解一下 redis-cell，现成的东西不要造轮子了

@tingyunsay 小项目去重应该直接 set()精确, 大项目才应该用 BloomFilter ?

GET API 是根据 ID 获取的过程，这个过程中你的目标是明确（且唯一的），包括需要在哪个分片进行获取

Query 的时候，根据你的条件（例如查询 id 为 xxx 的 doc ），在各个分片中进行“搜索”，获取各个分片符合条件的 doc 的 id，在协调节点中进行合并，合并结果回到分片中拿出完整数据（ query then fetch，如果是 query and fetch 等会略有不同）

这个头像好像能自动播放 BGM

虽然给不出什么实质性的建议，不过简历里面将各种技术、软件、项目等专有名词拼对是最基本的要求，例如你的 ES 拼写是错的...S 请转为 lowercase，另外应届的同学熟悉 ES 的话应该还是很有竞争力的，就看是不是真的“熟悉”了，祝好运

所以其实正确来说，不应该讲 MULTI 解释为事务，正确的认识是使用 MULTI 使得多个命令可以串行执行不被打断，至于从准备到开始执行过程中是否有变更使用 WATCH 来检查，一旦开始执行就会全部执行完毕不被打扰

@cuiweixie 恩理解你意思了，在 IOThreadMain 这段确实过掉了

@cuiweixie 一开始我也这样想过这段，不过后来觉得，比较好的流程应该是：
1、Master 准备这些 pending_list
2、Master 完成，进入 IO Thread 阶段，这时候 Master Thread 应该 act as IO Thread 来工作，而不是 sleep 等待
3、IO 阶段完成，Master 恢复处理 Master 的内容

这个想法是因为部分注释（读写都有）：
```
/* Also use the main thread to process a slice of clients. */
```
也就是说 Master 应该也会负责托管部分的 pending clients 么？ 所以没第一时间肯定，觉得晚上还需要再看看

@cuiweixie 对了虽然没搞懂哪里的代码是明确 Master 和 IO 分开执行，不过我之前这样理解是因为这个注释：
```
/* Process: note that the main thread will never touch our list
* before we drop the pending count to 0. */
```
所以在 IO Thread 执行过程中，Master 不会再去操作 io_threads_list 和 io_threads_pending。但是如您所说确实需要完整理解才能讲得清楚为什么不会同时执行。晚上下班后再康康

@cuiweixie 嗯嗯懂你意思了，先再读一下，这块了解得确实不够清晰

@cuiweixie 没有理解为什么会有线程切换？
我理解的模型是 Master Thread 处理完后，IO Thread 才会开始处理，而不会 IO Thread 和 Master Thread 一直在同一轮读写里面同时处理，Master Thread 完成执行完之后 IO Thread 才有机会 start，不存在 Master 代码段执行到一半的时候 IO Thread 也在执行某段代码，您觉得呢？

@cuiweixie
再稍微梳理一下我对读流程的理解，您要看一下是否一致先，因为我不是特别了解 C 和操作系统，所以可能一开始就是错的。

1、当读事件到来，也就是 Client 发送内容过来的时候，读事件 handler 不进行同步（/立即）处理，而是将他们放入待处理的队列。

2、`handleClientsWithPendingReadsUsingThreads()`方法构建 io_threads_list 与 io_threads_pending，其中 io_threads_list 是一个长度为 IO_THREADS_MAX_NUM 的指针 list，每个 item 都指向一个链表，链表中的元素为待处理的 client 对象。io_threads_pending 为一个长度与 io_threads_list 一致的整型 list，io_threads_pending[i]即为 io_threads_list[i]对应链表长度，也就代表着待处理的 client 数量。

3、回到你截图 2 的代码段（`*IOThreadMain`），listRewind 生成一个针对 io_threads_list[i]链表的迭代器，while 循环负责依次遍历 io_threads_list[i]链表中的各个 client （也就是待处理的任务），根据当前全局状态（读还是写），对 client 进行操作。


所以一个线程负责处理 io_threads_list[i]->client_1->client_2->client_3，其他线程也类似地负责处理 io_threads_list[j]中的各个 client 事件，这是我理解的模型。然后回到您的问题，我没太理解哪个位置的 data race，可能是对多线程的一些操作不是很熟悉和了解，请指教

@cuiweixie 有看到你在 google bbs 上发的内容，晚上再认真看看

@scriptB0y 嗯知道，博客上说了只支持，发布的时候决定兼容，我觉得现在如果抢推 RESP3 的话大概会给很多应用升级 Redis 6.0 带来困难吧至少短时间是这样的，包括生产里面很多客户端工具需要得到更新，比如 redis-py 目前也是 issue 但未实现，具体也需要看 RESP3 影响的是哪些命令的解析，其他语言 /生态同样有这些问题。

您的博客有一点就是这个“client”应该是执行 RAW 格式的命令，返回 RAW 结果，这点有好有坏个人认为，不过如果 client 都提供上 raw 命令的执行其实萝卜青菜各有所爱都能满足吧也挺好的。

BTW 看看友链~

Redis 6 不是只支持 RESP3 的，默认使用老版协议，但是可以手动改为使用 RESP3

给个建议写博客写公众号是个挺好的想法，但是如果和已有的轮子重合度太高其实很难被认可
https://www.elastic.co/guide/cn/elasticsearch/guide/cn/index.html

ES 这块现在比较缺少的资料例如最近几天我在学习看到的选举的 Bully 算法（ modified ）、分片的 PacificA 算法、Allocation 模块这类的知识会更加有价值。点开上面的链接可以看到你的文章和官方写的内容基本没有什么差别，这样博客就留不住用户了

@13192262269 老铁吃了核弹还是 TNT 23333 这么暴躁

@PanJiaChen
@xman2008xman 233333333333