scwMason的博客

这样看下来，写请求时有两种做法，删除缓存或者直接更新缓存，这两种做法看起来最终的效果一致，但是当我们从缓存利用率的角度出发，更新缓存会将所有更新DB的值都重新刷回缓存，如果大量的更新值都不会频繁读，那么这种策略就会导致大量的无效缓存，因此这种方案更适合读写流量差不多的情况下，写完后马上会被读的场景，否则，采用删除缓存的做法会更好，因为只有读时才会重刷缓存。因此我们今天讨论的问题就是在两种模式下，数据的增删改查出现缓存与数据库数据不一致的问题，为了更清楚，我们只拿只读缓存举例，最后对比一下两者即可。

然后我们先部署一主两从，编写docker-compose.yml，文件主要是创建了三个实例容器，并开启aof，分别映射到主机6379到6381三个端口上，并通过刚才创建的虚拟网卡进行通信和和分配ip​​​​​​​。验证没问题后我们开始部署哨兵实例，哨兵是特殊的Redis实例，因此我们先下载配置文件，并修改其中关于监控目标的实例地址信息，其中hostip设置成主机ip或者设置成主库在虚拟网卡上的ip也是可以的​​​​​​​。顺便写一个clusterStop.sh批量停止​​​​​​​。

Redis专栏合集【专栏】01| Redis夜的第一章【专栏】基础篇02| Redis 旁路缓存的价值【专栏】基础篇03| Redis 花样的数据结构【专栏】基础篇04| Redis 该怎么保证数据不丢失（上）【专栏】基础篇05| Redis 该怎么保证数据不丢失（下）【专栏】核心篇06| Redis 存储高可用背后的模式 前一节我们从存储高可用的角度讲了一下其背后的经典架构模式，数据库发展这么多年，发展到分布式、云计算、大数据的时代，单机一体化自然有些水土不服，随着Google的GFS、MapRed

通过前两节我们了解了在单实例下Redis是如何保证数据不丢失的，而作为NoSql的分布式键值数据库，往往以集群的方式提供服务才能保证所谓的”高可用“，而复杂度也会随着服务模式的改变而提升，多个实例之间的复制延迟导致的数据不一致、宕机实例的发现与切换等问题随之产生，这几乎是所有分布式存储都会遇到的问题，因此我们这一节抛开Redis，从存储高可用的角度看看背后的运作模式与规律。

Redis的数据可靠性保证我们就告一段落，这样看Redis在单机下既有了花样的数据结构保证了存储的多样性，也有了AOF和RDB保证了作为一个数据库的Crash Safe，而我们知道Redis属于键值数据库，键值数据库与传统关系型数据库最大的不同就是去关系，这也是NoSql数据库的最大特征，这也为分布式数据库做了铺垫，Redis作为分布式键值数据库，集群模式才是工业王牌，所以我们需要了解Redis是如何提供分布式服务的以及如何处理分布式系统的问题的，下期见~

AOF（Append Only File），从名字可以看出是一种追加写的文件，利用了磁盘顺序写比随机写高效的特性。我们直接看右边可以看到我们的操作'set'以及键和值的字符出现，除此之外还有*和$符号，这边稍微解释下，*后面的数字表示这个命令有几个部分，$后的数字表示每个部分有几个字节，这样再回头看是不是就清楚了，比如name有四个字节，所以就是$4。变成了只有三个元素的操作，格式也有了些变化，总体来说体积变小了很多，这就是AOF重写的作用，面向结果型的数据压缩，不记录中间过程。

上一节我们讲了Redis作为一个旁路缓存的基本工作模式以及旁路缓存的意义所在，也提到了Redis相比于简单的hashmap的get/set模式有更强大的支撑，其中Redis丰富的数据组织结构与巧妙的数据存储结构是Redis广受欢迎的原因之一，这一节我们就来看看Redis花样的数据结构。

这一小节我们了解了旁路缓存以及旁路缓存的工作模式，Redis作为一款旁路缓存系统，本质是数据服务，我们上面举了一个hashmap的例子粗糙地形容了一下基本读写功能，而Redis作为最受欢迎的旁路缓存，它丰富的数据结构是其地位不倒的重要原因之一，除了字符类型我们有各种奇奇怪怪的存储需求比如队列、集合或者是map甚至是定制的数据结构，本质是服务于业务，因此我们下一节会介绍Redis的基本数据结构，看看Redis是如何高效地利用珍贵地内存资源的。只读缓存将最新的数据维护在DB中，缓存不用关心数据的可靠性。