2019-10-22大概总结了一下：
实现高可用的核心依旧是集群。多个缓存节点，提高容错率。
客户端实现：由客户端的策略决定如何写缓存，如何读缓存。性能高，但是逻辑复杂，无法跨平台。
中间件实现：所有客户端先访问中间件，然后中间件决定了缓存策略。因为引入了中间件，所以性能较差，但是可以跨平台，并且有能力的公司还可以自研中间件。
服务端实现：主从切换由服务端实现。最大的缺点是增加了运维成本。
不知道我的理解是否正确。展开作者回复: 是的👍
6
2019-10-18打卡。 老师好，提问：一致性Hash中，比如存在A(k1)、B(k2)、C(k3)，3个节点，括号中为分配的Key，假如B节点剔除了，那么k2会漂移到C节点。 那么此时客户端请求get k2的时候，是被计算好从C节点获取呢，还是完全就拿不到需要去数据库查？如果是从C节点获取，那感觉命中率完全没有下降。 这一点确实没搞清楚，忘老师解惑，谢谢🙏作者回复: 1. 如果B节点剔除，那么K2的读写都会到C节点上
2. 命中率会下降，因为B节点没有被删除的时候，C节点上是没有K2数据的。B节点剔除后，第一次从C节点获取K2数据是要穿透的 2 6
2019-11-03回答一下问题，如果缓存的高可用做的不够好的话，一旦线上发生故障，导致缓存直接崩了，再加上并发量比较大的话，可能会直接去访问数据库了，对数据库的压力比较大，严重的话，会导致数据库崩溃，然后就是各种丢数据，然后关于如何做的话，建议之前做好关于一些流量的评估，以Redis为例，现在有现成的哨兵和集群方案可以使用，当然也可以Codis，还有一点就是部署线上的时候可以先演练下 3- 2019-10-22另外就客户端和服务端的理解：
老实说一开始我也一脸懵逼。以为客户端就是用户端。
但是后来想通了。
应用服务器为用户提供数据接口，用户就是客户端，应用就是服务端。
但是缓存为应用服务器提供缓存服务，这时候对于缓存服务器来说应用服务器就是客户端，而缓存就是服务端。作者回复: 是的 ：）
2 
2019-12-19老师，Redis Cluster中使用了hash槽，我理解跟一致性hash其实是等价的，对吧。不过，Redis在分片间还实现了在新增节点时自动迁移数据作者回复: 算法上不太一样哦
1- 2019-12-18老师，主从会有延迟，写入主库，但延迟同步到从库，在同步完成前去从库读数据，读不到，这如何解决呢
作者回复: 1. 写入的时候中缓存，这样从缓存里面读就实时了
2. 直接读主库 1 
2019-11-06分享一個踩過的坑，在AWS上，產品經理要做一個增加搜索速度的功能，要求把最近搜過的關鍵字跟結果緩存起來，於是就通過AWS elastic cache做了一盒緩存層，然後產品經理提出我們的項目是跨region訪問的，我在A region更改數據後在瞬間開另一個瀏覽器用deep link方式從B region再訪問，都要看到數據，然而AWS的緩存不支持跨region的數據拷貝，於是這個story的failure就變成我來背鍋 1
2019-11-04还没看完就想说一下我之前的做法，我们有两级缓存，服务器应用程序自身有一个内存缓存，再有Redis缓存，如果内存缓存没有命中，应用程序会创建一个单机的资源锁（go语言，用map+chan实现），大量请求进来，只有第一个请求会获取锁，其他请求获取锁失败，调用wait方法，等待第一个请求获取数据，第一个请求先从Redis中获取数据写入到内存缓存，Redis没有命中再读取MySQL，写会到Redis，执行结束后会通过close chan的方式广播消息，通知其他请求拿到了数据，从内存中读取数据，再释放锁。这样就解决了缓存穿透的问题，同一时刻，不论多大的并发量，真正到存储查询数据的请求只会有一个。作者回复: 其实更多的会在redis和mysql之间增加并发的控制，因为redis还是可以扛很好的并发的
5 1
2019-10-29老师，这个客户端方案中的客户端指哪里。一般我理解的客户端是浏览器或手机app...作者回复: 指的是你的应用服务器，是缓存的使用者
1
2019-10-25老师，memcached的主从机制会考虑分片实现多个主吗，还是单机全量？多副本方案中提到会选用一个主从作为一个副本组，是一个master多个slave的结构吗？但是画图没有标示这种结构作者回复: 1. 会考虑分片
2. 是的 1
2019-10-18老师，repcached 算不算 memcached 的服务端高可用方案作者回复: 算是吧~
1
2019-12-31老师，多副本能举个例子吗？这块没看明白
先是说一组slave会有问题
在这个方案中，当客户端发起查询请求时，请求首先会先从多个副本组中选取一个副本组发起查询，如果查询失败，就继续查询 Master/Slave，并且将查询的结果回种到所有副本组中，避免副本组中脏数据的存在。
最后说在实践中我们会把 Master 和 Slave 作为一组副本组使用。展开作者回复: 多副本你可以认为是缓存的缓存，也就是在缓存之上再加一组缓存，可以解决单组缓存的带宽瓶颈
而在实践过程中，因为大部分流量都会被副本承担，master和slave的数据有可能会变得不热，所以可以把master和slave当做副本
2019-12-23redis cluster能不能详细的说说呢？
2019-12-05老师 最近学习 这里还有一个问题 在Redis的sentinal方案中 读缓存是读Slave结点吗？？ 感觉只有读Slave结点 才能实现更高的读请求性能 但是读Slave节点时 Master中的数据还没有同步过来 没有读到结果 或者读到旧数据脏数据的话 这个应该怎么解决 ？？？ 还是说 读请求也只能读Master结点作者回复: 这个和sentinal无关的。只要做了主从分离，读的都是slave节点。sentinal是来监控主库，在主库出现问题的时候可以帮助你做从库提主
2019-11-28老师，那个多副本那块，是每个副本里面存着三个缓存的的热点数据还是，对应的缓存有个副本作者回复: 每个副本里面都有热数据
2019-11-23老师，Redis没有部署哨兵之前，使用集群部署。当单台服务器出现故障时，造成部分片区不可用，Redis是怎么解决这个问题的？还是根本就没解决呢？
按老师的思路我觉得会有几种方案：
第一种方案：Redis设置该片区不可用，然后顺延到下一个片区。
第二种方案：运维手工解决，把这个片区划分到其他片区，也就是重新分片。
2019-11-13老师您好，文中的多副本可以解决缓存的热点数据的问题吗？我的理解是在应用服务和缓存服务之间加本地缓存层存储热点数据，起这样吗？还有没有其他解决缓存的热点数据的方式？作者回复: 多副本应该可以一定程度上缓解热点数据的问题，因为它的一个主要作用就是抗流量
本地缓存确实可以解决热点的问题- 2019-11-12请教下，中间层代理方案和服务端方案有什么不同吗？文中没有详细说明哦。
作者回复: 服务端方案是组件自带的，代理层是在组件之上的
2019-11-11它将一个缓存节点计算多个 Hash 值分散到圆环的不同位置，这样既实现了数据的平均，而且当某一个节点故障或者退出的时候，它原先承担的 Key 将以更加平均的方式分配到其他节点上，从而避免雪崩的发生。
老师，这句话啥意思了？是说把一个节点分布到多个位置？作者回复: 是的，因为虚拟了多个节点，这些节点会分布在圆环的多个位置
- 2019-11-07老师请教一下 客户端一致性哈希算法 四到六个结点 如果四个结点的话 删除一个结点 依然会有四分之一的请求无法命中缓存 感觉这个一直性哈希算法和普通的哈希算法 没有太大区别呀 老师能不能再仔细简介一下这个地方 看不出一致性哈希算法的优势
作者回复: 在一致性hash下，如果删除一个节点，比如在一个环上有a，b，c三个节点，b故障，那么只有b的数据会迁移到c上；但是普通hash会重新计算hash值，理论上会影响所有的数据
1