同问价格

@zhengyouxiang 就是方框方框加方框呀 其实仔细看图里面也没什么高大上的元素在 就方框文字方框文字箭头

@mightofcode 哈哈，那

Redis 的 ieda 是把接收到的事件都延迟进行处理，比如积累了一堆读事件（用户发命令过来），延迟之后用多线程读取，然后单线程顺序执行；写也是一样，把很多个已经准备好回复内容的连接累积起来，晚一点再用多线程写给各个 client

@ppolanwind 如果你说的是图片的话 用 sketch 画的

@lidlesseye11 hhhh 开头有邮箱了 欢迎交流安利

用你的新机器做 slave，旧机器做 master，等同步完毕之后旧机器就有对应数据了；
考虑到你说只有 1w 条，那么场景必然是可以容忍 master 停写的，很容易达成两台机器数据一致

em 补充一点，在字段少（但不仅有 id, c1, c2 ）的情况下，如果 c1, c2 是 varchar 之类的类型，未必会真的选择(c1, c2)索引进行索引扫描，因为选择使用什么查询路径是根据 cardinality 值来决定的，这个值是通过定期对页进行采样、统计的结果，是个预估值，如果不巧 mysql 记录的主键索引和(c1, c2)索引的预估值与实际不符，那有可能会采取（实际性能更差）的主键扫描来执行

心疼楼主...还有这么多人说走全表，一定要坚持有自己的观点呀^_^特别是你觉得有足够的东西支撑观点的时候

这个查询毫无疑问（正常情况下）会走你的(c1, c2)索引，前提是你的表可能得不止有 id, c1, c2 这 3 个字段，理由是主键索引的每个页能够存放下的数据行比(c1, c2)索引每个页能存放下的数据行更少，如果扫描主键获取结果，需要扫过更多的数据页，如果扫(c1, c2)索引，尽管没有用上"索引"的查询特性，但是可以通过扫更少的页得到正确结果。

性能的差距 = 主键索引体积 vs (c1, c2)索引体积，当你的表字段越多，越大的时候，差距越明显；反例则是如果表只有 id, c1, c2 三个字段的时候，扫描的时间理论上应该是非常接近的，并且优化器在选择上两个索引都有可能选择使用

...大小写错了不觉得看起来很碍眼么。。。

@wangyanrui 哨兵仅仅是 Redis 高可用的方案之一，而 Cluster 是同时做了高性能和高可用的方案，并不是只是组集群发挥更高性能而已，所以~建议下次指点别人之前确认自己的理解是正确的，不然就，hhh 蛮尴尬^_^

@wangyanrui 你理解得不对，是不是以为 Redis Cluster 是几台机器组起来的集群，然而其实并不是，典型的架构是例如起 3 主 3 从的 Redis Cluster，这里面会包括有了当主节点挂掉的时候，从节点接替继续工作的 Feature，而不是挂了其中之一就挂掉，所以这两者是有可比性并且哨兵确实就是落后的。

多捞啊...书都不能拿纸笔写写画画了，我为啥还要买你这书

1 楼正解，BloomFilter 处理超大数据量天然优势

@ClericPy 为什么要 ignore missing imports...

再安利最近写的 Redis 6.0 一些新功能的实现的文章：

Redis 6.0 ACL 基于 Bitmap 实现： https://blog.2014bduck.com/archives/343
Redis 6.0 多线程 IO 的实现： https://blog.2014bduck.com/archives/326

文章在 V2EX 上也能找到~不过安利博客大概可以流量+1

我是 小黄鸭 @Shopee ^_^

@hello2060 拿纸写完拍照更麻烦呀，人家现在这个时间问，肯定是因为疫情远程面试，不然谁买板子

@b821025551b 是不是有啥文字表达的误会 2333 我看 youtube 上的 up 主（放心我看的不是印度的小哥）也是这样年的呀 steam

想深入了解的话，github 上 pingcap 的一个 awesome database 的 repo （名字大概有点偏差）