《Redis 核心技术与实战》学习笔记 05

学习极客时间《Redis 核心技术与实战》专栏过程中的一些学习笔记，部分已经作为留言发布，但是留言太多，排在后面的一般很难被大家看到，所以集中发布在这里，欢迎讨论。

题图来自《Redis 核心技术与实战》专栏

09 | 切片集群：数据增多了，是该加内存还是加实例？     

纵向扩展 scale up 和横向扩展 scale out 是当业务遇到大数据的两种选择，而目前来看，分布式也就是横向扩展无疑是占据了主流地位。很早以前，似乎就有传说，谷歌使用了成千上万台 PC 级别的电脑，组成了强大的分布式搜索引擎集群。

现在，有很多应用开始云上部署，那么横向扩展似乎也就成了应有之意。

横向扩展相对纵向扩展，还有一个好处就是比较容易做成高可靠性的集群，人多力量大，或者是蚁群战术。

16384 是 2 的 14 次方，估计是用了两个字节来存储槽位信息，剩余两个比特位可能是校验，也可能是其他。

手动分配，要把 16384 个槽都分配完，这个明显是不希望手动分配啊。（看到留言里面有 0~5000, 5001~10000, 10001~16383 的分配方式）。

另外没有采用一致性哈希算法，我觉的也是因为目前的这种方式相对简洁、快速。

对于课后思考题：

对键值对的 key 做 CRC 计算，然后在和哈希槽映射，这两个计算过程实际上是非常快的，甚至有可能比查一张大表（O(n)）更快。另外，通过计算的方式，也更加灵活一些。

如果使用一个表直接把键值对和实例的对应关系记录下来，那么这个表就会成为瓶颈，或者单点故障。另外多个 Redis 节点之间如何同步表的信息也会非常麻烦。

学习了课代表 Kaito 的留言，发现自己错过了哈希槽几个要点，一个是集群中的 key 无法预估，有可能很多，内存占用不可控；另一个是哈希槽可以让数据和节点解耦，数据分配更加均匀。

10 | 第 1～9 讲课后思考题答案及常见问题答疑

这一讲应该是对前面 9 讲一次很好的复习与回顾，其中一些课后题我也试着思考过，其中大部分都距离标准答案有一些距离。

其实我觉得这是一种很好的回顾方式，希望极客时间以后的专栏都能采取类似的方式，有课后思考题，有解答，当然还要有课代表。

课代表同学这次没有出现，让人感觉似乎少了点什么。