内存数据库Redis
本文篇幅很长，整理了Redis的核心知识作为笔记。更多学习Redis的学习资源应该是来自于官网：http://redis.io/ 和 http://www.redis.cn/
理论知识
Redis作为现在最为热门的NoSQL服务器，要突兀的讲述一些关于Redis的理论知识突然不知道怎么写的很有结构性，只好将各个知识点罗列出来，如下：
首先得知道Redis是什么，能干嘛
Redis（REmote DIctionary Server）远程字典服务器
首先对于Redis的定位永远是一个分布式内存数据库。
是完全开源免费的，用C语言编写的，遵守BSD协议，是一个高性能的(key/value)分布式内存数据库，基于内存运行，并支持持久化的NoSQL数据库，是当前最热门的NoSql数据库之一,也被人们称为数据结构服务器。
Redis 与其他 key - value 缓存产品相比有以下三个特点：
1、 Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用
2、 Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储
3、 Redis支持数据的备份，即master-slave模式（主从）的数据备份
使用Redis我们可以做这些事情：
1、内存存储和持久化：redis支持异步将内存中的数据写到硬盘上，同时不影响继续服务
2、取最新N个数据的操作，如：可以将最新的10条评论的ID放在Redis的List集合里面
3、模拟类似于HttpSession这种需要设定过期时间的功能
4、发布、订阅的消息系统
5、定时器、计数器
CAP理论
- Consistency 强一致性
- Avaibility 高可用性
- Partition tolerence 分区容错性
CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：
1、CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
2、CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。
3、AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。
P原则在分布式系统中已经是必须保证的，剩下的C和A怎么选择呢？
对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低， 有些场合对写一致性要求并不高。允许实现最终一致性。数据库的写实时性和读实时性需求，对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。
对复杂的SQL查询，特别是多表关联查询的需求，任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特别是SNS类型的网站，从需求以及产品设计角 度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。
BASE理论
分布式事务DASE理论就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。
BASE其实是下面三个术语的缩写：
基本可用 （Basically Available）
软状态 （Soft state）
最终一致 （Eventually consistent）
它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么这么说呢，缘由就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这些指标，要想获得这些指标，我们必须采用另外一种方式来完成，这里BASE就是解决这个问题的办法。
其实BASE理论在消息中间件结合分布式数据访问的时候运用更为广泛
其他跟Redis相关的概念
-
分布式系统（distributed system）
由多台计算机和通信的软件组件通过计算机网络连接（本地网络或广域网）组成。分布式系统是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。分布式系统可以应用在在不同的平台上如：Pc、工作站、局域网和广域网上等。
简单来讲：
1分布式：不同的多台服务器上面部署不同的服务模块（工程），他们之间通过Rpc/Rmi之间通信和调用，对外提供服务和组内协作。
2集群：不同的多台服务器上面部署相同的服务模块，通过分布式调度软件进行统一的调度，对外提供服务和访问。 -
NoSQL数据库分类
分为四类，分别是：
1、KV键值（Redis,Memcache）
2、文档型数据库(MongoDB,CouchDB)
3、列存储数据库(大数据中用的HBase)
4、图形关系数据库(Neo4J) -
Redis的官方性能介绍是，写：8万/秒 读：10万/秒
-
单进程
单进程：单进程模型来处理客户端的请求。对读写等事件的响应。是通过对epoll函数的包装来做到的。Redis的实际处理速度完全依靠主进程的执行效率。epoll是Linux内核为处理大批量文件描述符而作了改进的epoll，是Linux下多路复用IO接口select/poll的增强版本，它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用率。 -
NoSQL 不是 NO！SQL ，而是 Not Only SQL
Redis数据类型
下面介绍数据类型，但是不再详细介绍任何命令，在http://www.redis.cn/commands.html
页面上有非常详细的命令大全。
1、String（字符串）
string是redis最基本的类型，你可以理解成与Memcached一模一样的类型，一个key对应一个value。
string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象 。
string类型是Redis最基本的数据类型，一个redis中字符串value最多可以是512M
2、Hash（哈希）
Redis hash 是一个键值对集合。Redis hash是一个string类型的field和value的映射表，hash特别适合用于存储对象。类似Java里面的Map
3、List（列表）
Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素导列表的头部（左边）或者尾部（右边）。它的底层实际是个链表
4、Set（集合）
Redis的Set是string类型的无序集合。它是通过HashTable实现实现的。
5、zset(sorted set：有序集合)
Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。zset的成员是唯一的,但分数(score)却可以重复。
Redis配置文件
关于Redis的配置文件，每一个配置都会有非常详细的英文解释，一般在安装目录下面会找到。
常用的如下：
redis.conf 配置项说明如下：
-
Redis默认不是以守护进程的方式运行，可以通过该配置项修改，使用yes启用守护进程
daemonize no -
当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定
pidfile /var/run/redis.pid -
指定Redis监听端口，默认端口为6379，作者在自己的一篇博文中解释了为什么选用6379作为默认端口，因为6379在手机按键上MERZ对应的号码，而MERZ取自意大利歌女Alessia Merz的名字
port 6379 -
绑定的主机地址
bind 127.0.0.1 -
指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为verbose
loglevel verbose -
日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null
logfile stdout -
设置数据库的数量，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id
databases 16 -
指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合
save
Redis默认配置文件中提供了三个条件：
save 900 1
save 300 10
save 60 10000
分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。 -
指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大
rdbcompression yes -
指定本地数据库文件名，默认值为dump.rdb
dbfilename dump.rdb -
指定本地数据库存放目录
dir ./ -
设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master进行数据同步
slaveof -
当master服务设置了密码保护时，slav服务连接master的密码
masterauth -
设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH 命令提供密码，默认关闭
requirepass foobared -
设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
maxclients 128 -
指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理 后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区
maxmemory -
指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no
appendonly no -
指定更新日志文件名，默认为appendonly.aof
appendfilename appendonly.aof -
指定更新日志条件，共有3个可选值：
no：表示等操作系统进行数据缓存同步到磁盘（快）
always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全）
everysec：表示每秒同步一次（折衷，默认值）
appendfsync everysec -
指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中（在后面的文章我会仔细分析Redis的VM机制）
vm-enabled no -
虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享
vm-swap-file /tmp/redis.swap -
将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0
vm-max-memory 0 -
Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的 数据大小来设定的，作者建议如果存储很多小对象，page大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不 确定，就使用默认值
vm-page-size 32 -
设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存。
vm-pages 134217728 -
设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4
vm-max-threads 4 -
设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启
glueoutputbuf yes -
指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法
hash-max-zipmap-entries 64
hash-max-zipmap-value 512 -
指定是否激活重置哈希，默认为开启（后面在介绍Redis的哈希算法时具体介绍）
activerehashing yes -
指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件
include /path/to/local.conf -
当 客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能
timeout 300
接下来才进入重点知识
Redis持久化
Redis持久化的方式有两种，分别是RDB和AOF，两者的开启都需要去配置文件中指定，可以共存，共存的时候在启动的时候会优先加载AOF的文件，下面详细介绍着两者方式。
RDB
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
RDB是整个内存的压缩过的Snapshot(快照)，RDB的数据结构，可以配置复合的快照触发条件，默认是1分钟内改了1万次，或5分钟内改了10次，或15分钟内改了1次(在配置文件中可以看到三行数据 save的数据的 )。
这是自动触发的备份，想要立即将数据写入备份文件可以使用save命令。如果想要禁用就在配置文件里面给save设置一个空参数，或者不设置如何save命令。
恢复数据其实就是将备份的dmp文件放到启动的目录下直接启动就好，所以从这里可以看出，Redis是可以做序列化的。（序列化说白了就是将对象写成文件的形式存储起来）
RDB的优劣势
优势：适合大规模的数据恢复，对数据完整性和一致性要求不高。
劣势：在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改，fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑。
AOF
以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
理解：像影子一样，你什么操作我就记录什么操作。Aof保存的是appendonly.aof文件
appendonly.aof和dump.rdb文件可以共存，启动的时候是先去按照appendonly.aof记录的去恢复数据，但是如果appendonly.aof文件中有不符合规范的代码就会导致redis启动不起来。但是可以使用redis-check-aof –fix进行修复，然后重启redis就能恢复数据。
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制,当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。
重写原理：AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似触发机制：Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发，但一般大型的互联网公司都是很大。
优劣势
优势：每修改同步：appendfsync always同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好。可以设置为：
每秒同步：appendsync everysec 异步操作，每秒记录，如果一秒宕机，有数据丢失
不同步：appendfsync no 从不同步
劣势：相同数据集的数据而言，aof文件要远远大于rdp文件，恢复速度慢于rdp
aof运行效率要慢于rdp，没秒钟同步策略效率较好，不同步效率和rdp相同。
RDB和AOF如何选择
1、RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
2、AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
3、如果对redis的定位仅仅只是缓存，如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式。
4、可以同时开启两种持久化方式
在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
5、性能建议
因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。
如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。
Redis事务
Redis的事务对比传统关系数据库的事务来说，可以说简单了不止一点半点，仅仅用屈指可数的几条命令加上一个watch的机制就可以实现事务，不可谓不强。
但是在这之前笔者决定先记录一下Mysql中悲观锁、乐观锁、表锁、行锁、间隙锁的知识。
为什么要说锁，还这么多锁，其实就是一个很简单的道理：数据的一致性和并发性是必定存在冲突的。
概述
锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。
为了尽可能提高数据库的并发度，每次锁定的数据范围越小越好，理论上每次只锁定当前操作的数据的方案会得到最大的并发度，但是管理锁是很耗资源的事情（涉及获取，检查，释放锁等动作），因此数据库系统需要在高并发响应和系统性能两方面进行平衡，这样就产生了“锁粒度（Lock granularity）”的概念。一种提高共享资源并发发性的方式是让锁定对象更有选择性。尽量只锁定需要修改的部分数据，而不是所有的资源。更理想的方式是，只对会修改的数据片进行精确的锁定。任何时候，在给定的资源上，锁定的数据量越少，则系统的并发程度越高，只要相互之间不发生冲突即可。
行表锁
使用Mysql的MyIsam引擎一般加锁都是表锁，数据一致性得到保障，但是并发程度得不到保障。
而行锁则偏向InnoDB存储引擎，开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度也最高。
InnoDB与MyISAM的最大不同有两点：一是支持事务（TRANSACTION）；二是采用了行级锁，varchar类型转换可能导致行锁边表锁
间隙锁
update test_lock set b = a *20 where a>1 and a<5;
想这样的SQL语句就会出现间隙锁，就是带范围带事务的SQL语句。
当我们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但并不存在的记录，叫做“间隙（GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁（GAP Lock）。
因为Query执行过程中通过过范围查找的话，他会锁定整个范围内所有的索引键值，即使这个键值并不存在。
间隙锁有一个比较致命的弱点，就是当锁定一个范围键值之后，即使某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无法插入锁定键值范围内的任何数据。在某些场景下这可能会对性能造成很大的危害
如何锁定一行？ select * from test_innodb_lock where a=8 for update;
Innodb存储引擎由于实现了行级锁定，虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会要更高一些，但是在整体并发处理能力方面要远远优于MyISAM的表级锁定的。当系统并发量较高的时候，Innodb的整体性能和MyISAM相比就会有比较明显的优势了。
但是，Innodb的行级锁定同样也有其脆弱的一面，当我们使用不当的时候，可能会让Innodb的整体性能表现不仅不能比MyISAM高，甚至可能会更差。
悲观锁和乐观锁
了解了MySQL中两种存储引擎的锁机制，再来看看悲观锁和乐观锁：
悲观锁：悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
乐观锁：乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，
乐观锁策略:提交版本必须大于记录当前版本才能执行更新
当然，悲观锁也有用，就是在数据库备份数据的时候将整张表锁掉，再去执行备份脚本，就比较安全。
工作中一般用的都是乐观锁。
乐观锁的工作情况是：
假设一张数据表有以下字段，ID,NAME,AGE
操作员A想修改name字段，操作员B想修改age字段，并发情况如下
A拿到数据，此时数据版本是1，正在修改name中…
0.05秒之后2拿到数据，版本依旧是1,因为A还没有提交事务，B迅速的改好了age字段，提交事务，这时这条记录的版本会变成2,
A修改name字段完毕，此时提交会失败，因为数据库里面已经有版本号为2的数据了，他提交成功会导致B的修改无意义，所以A只能拿到最新版本的数据再去修改数据，提交事务。
Redis事务
Redis关于事务的命令只有5个：
1、discard 取消事务，放弃执行事务块内的所有命令
2、exec 执行所有事务块内的命令
3、multi 标记一个事务块开始
4、watch 监视一个key或者多个key,如果在这事务执行之前这些key被其他命令所打动，那么这些事务就将会被打断
5、unwatch 取消watch命令对所有key的监视
使用
正常执行事务如下
放弃事务如下
写了错误的命令，全体事务命令不能执行，如下
进行了错误的操作，但命令没有写错，如下
从这里我可以看出Redis对事务四部分支持的，不像传统的关系型数据库要求绝对的数据一致性。
使用watch
watch的数据被别修改之后：
Watch指令，类似乐观锁，事务提交时，如果Key的值已被别的客户端改变，比如某个list已被别的客户端push/pop过了，整个事务队列都不会被执行。通过WATCH命令在事务执行之前监控了多个Keys，倘若在WATCH之后有任何Key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败。
Redis事务三阶段
1、开启：以MULTI开始一个事务
2、入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面
4、 执行：由EXEC命令触发事务
Redis事务三特性
1、单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
2、没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题。
3、不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。
Redis主从复制
当Redis很轻松的就实现了主从复制，读写分离的时候，你还在犹豫什么？凭什么不用？凭什么不学？
用到的命令直接看截图实例
主仆模式
正常使用的情况如下四张图：
主机从机争取同一个值时候，从机失败，情况如下一张图：
主机宕机的情况如下两张图：
从机宕机的情况如下两张图：
传递模式
避免了中心化太严重的情况（但是在后面的演示中会发现这种模式其实并不是很理想）
上一个Slave可以是下一个slave的Master，Slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master,可以有效减轻master的写压力
中途变更转向:会清除之前的数据，重新建立拷贝最新的
命令： slaveof 新主库IP 新主库端口
直接看图，正常运行的情况如下两张图：
主机宕机的情况如下两张图：
中间节点宕机的情况如下三张图：
尾节点宕机的情况如下两张图
反客为主
slaveof no one 使当前数据库停止与其他数据库的同步，转成主数据库
当主机宕机了之后，一主二仆模式的两个从机会等待重新连接。使用这个命令可以称为主机。
反客为主如下图：
主从复制的原理
1、slave启动成功连接到master后会发送一个sync命令
2、Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave,以完成一次完全同步
3、全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
4、增量复制：Master继续将新的所有收集到的修改命令依次传给slave,完成同步
5、但是只要是重新连接master,一次完全同步（全量复制) 将被自动执行
哨兵模式
哨兵模式是很常用的，就是反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。需要去配置文件中指定投票策略，然后开启一个用于监控Redis集群的进程，之后就什么都不用做了，当master宕机之后，这个程序会自动选出新的master。
1、开启这个监控的程序
2、启动Redis,模拟宕机情况如下两张图：
在这种哨兵模式下：
由于所有的写操作都是在Master上操作，然后同步更新到salve上，所以从Master同步到slave机器上会有一定的延迟，当系统繁忙的时候，延迟会导致严重的问题，slave机器数量的增加也会使得这个问题更加严重。
Jedis
Jedis是一套使用Java代码操作Redis集群的API，在代码里写各种种命令。类似于操作Hadoop的HDFS文件系统、Zookeeper使用客户端操作集群的代码。
具体常用的代码接口其实非常非常简单，个人GitHub：https://github.com/xiaoshaDestiny/LearnJedis
鸣谢
本文章是Redis的笔记，来自于周阳老师的redis课程。
微服务，是不是也会将数据库拆分呢？总是以为将数据放在一个统一的地方，使用统一的读取方法会方便。于是有了关系型数据库，而分布式集群时代的到来，这却变成了最令人诟病的地方，我们又尝试将数据分库分表，主从复制，读写分离…以适应高并发的实际情况。淘宝的去IOE进化过程就是这十几年我们队数据的重新认识。如果将数据分门别类，会给我们管理数据带来什么样的挑战，是否已经有一套关于数据拆分这样的标准？行业在发展，需要不断思考与探索，每一个天上飞的理念都会有落地的实现。