Redis与Mencached

Reids与Memcached

Redis是一个继memcached后的又一个第三方缓存数据库，他比memcached强大很多，支持更多的数据类型（String、list、set、sort set、hash），支持持久化，支持集群；Redis虽然支持持久化，但是他并不适合持久化的保存数据。因为他不是很稳定。但是由于他是保存在内存中，读取速度非常快，所以在项目中一般都用它作为数据库和应用程序直接的中间层来使用，已减轻数据库压力，提高运行效率。
我们项目中很多地方用到了redis；比如商品的三级分类、省市县、关于我们、联系我们、友情链接，常见问题等经常查询但是不经常改变的数据.redis还可以在tomcat集群里边实现session的共享。由于他的单线程的，所以在电商平台里边也经常用他做“防止超卖”, 生成规则的商品编号等。还有就是购物车也用到了redis
代码中，我们一般都通过spring整合redis官方提供的jedis工具包来操作redis。可以是单机版，也可以是集群。Redis本身就支持集群操作redis_cluster，另外redis还支持主从复杂，还有他独特的哨兵模式，在主服务器宕机时，从服务器可以自动转换为主服务器。另外，他也有他的分片机制，就像mysql的水平分表设计，数据量大时，可以把数据存储到不同的库中，来减轻redis负担。
1、什么是redis?
Redis 是完全开源免费的，遵守 BSD 协议，是一个高性能的 key-value 数据库。
Redis 与其他 key - value 缓存产品有以下三个特点：
Redis 支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次
加载进行使用。
支持丰富数据类型，支持string，list，set，sorted set，hash
Redis 支持数据的备份，即 master-slave 模式的数据备份。

2、Redis 应用场景
主要能够体现 解决数据库的访问压力。
例如:短信验证码时间有效期、session 共享解决方案

3、Redis 优势
速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)
性能极高 – Redis 能读的速度是 110000 次/s,写的速度是 81000 次/s 。
丰富的数据类型 – Redis 支持二进制案例的 Strings, Lists, Hashes, Sets 及
Ordered Sets 数据类型操作。
原子 – Redis 的所有操作都是原子性的所谓的原子性就是对数据的更改要么全部执行，要么全部不执行 ，同时 Redis 还支持对几个操作全并后的原子性执行。
丰富的特性 – Redis 还支持 publish/subscribe, 通知, key 过期等等特性。
丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除

4、为什么redis需要把所有数据放到内存中？
Redis为了达到最快的读写速度将数据都读到内存中，并通过异步的方式将数据写入磁盘。所以redis具有快速和数据持久化的特征。如果不将数据放在内存中，磁盘I/O速度为严重影响redis的性能。在内存越来越便宜的今天，redis将会越来越受欢迎。
如果设置了最大使用的内存，则数据已有记录数达到内存限值后不能继续插入新值。

5、Reids的特点　　
　　Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。
　　Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存多种数据结构，此外单个value的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性 能消息队列服务，用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一个功能加强版的memcached来用。
　　Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
　　
6、redis常见性能问题和解决方案
1).Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要写内存快照。
2).Master AOF持久化，如果不重写AOF文件，这个持久化方式对性能的影响是最小的，但是AOF文件会不断增大，AOF文件过大会影响Master重启的恢复速度。Master最好不要做任何持久化工作，包括内存快照和AOF日志文件，特别是不要启用内存快照做持久化,如果数据比较关键，某个Slave开启AOF备份数据，策略为每秒同步一次。
3).Master调用BGREWRITEAOF重写AOF文件，AOF在重写的时候会占大量的CPU和内存资源，导致服务load过高，出现短暂服务暂停现象。
4). Redis主从复制的性能问题，为了主从复制的速度和连接的稳定性，Slave和Master最好在同一个局域网内

7、redis持久化的几种方式
Redis的持久化方式主要有2种，RDB和AOF，RDB是一种快照方式，默认每隔5分钟创建一个快照副本，这种方式占用空间大，而且会丢失间隔时间5分钟之内的数据，但是他适合做备份，恢复时，可以根据需要恢复任意间隔时间点的数据。AOF是一种日志的持久化记录方式，每秒钟，都把redis中新增的数据记录到日志文件中，这种方式只有一个文件，占用空间少，最多丢失1秒内的数据。相对比较好，但是如果想要恢复5分钟或10分钟前某个时间点的数据，就不行了。所以实际项目中，我们一般会两种方式同时使用。如果搭建集群的话，还可以通过集群互相备份数据，只要集群不同时挂掉，单个redis就可以从集群中的其他服务器获取到最新数据。
RBD:默认是开启的
在某个时间点将数据写入一个临时文件,持久化结束后,用这个临时文件替换上次持久化的文件,达到数据恢复.
优点:使用单独子进程来持久化,主进程不会进行任何IO操作,保证了redis的高性能
缺点:RDB是间隔一段时间进行持久化,如果持久化之间redis故障,会数据丢失.这种方式更适合数据不严谨的时候
AOF:默认是关闭的,可以修改配置文件redis.config:appendonly yes开启
优点:可以保持更高的数据完整性,如果设定追加file的时间是1s,那么丢失的数据最多就是1s内的数据
缺点:日志文件大,恢复速度慢
AOF与RDB两者区别:
.1. Rdb---->备份数据
Aof----->备份指令
.2.AOF更加安全,数据同步更加及时
RBD安全性相对较差
.3.AOF文件大,文件内容恢复相对较慢.
RDB文件尺寸小,恢复速度快

8、redis的主从结构
主从结构一是可以进行冗余备份,二是可以实现读写分离
主从复制
redis的复制功能是支持多个数据库之间的数据同步.
一类是主数据库(master),一类是从数据库(slave).主数据库可以进行读写操作,当发生写操作时,自动将数据同步到从服务器;而从服务器一般时只读的,并接收主数据库同步过来的数据;一个主数据库可以有多个从数据库,而一个从数据库只能有一个主数据库.
通过redis的复制功能可以很好的实现数据库的读写分离,提高服务器的负载能力,主数据库主要进行写操作,而从数据库扶着负责读操作.
读写分离
主从架构中，可以考虑关闭主服务器的数据持久化功能，只让从服务器进行持久化，这样可以提高主服务器的处理性能。从服务器通常被设置为只读模式，这样可以避免从服务器的数据被误修改。

9、事务
redis事物可以一次执行多个命令,并且保证原子性和隔离性;
隔离性:事物中的所有命令都会序列化,按顺序执行.事物在执行的过程中,不会被其他客户端发送来的命令打断.
原子性:事务中的命令要么全部执行,要么全部都不执行.
一个事物一般会经历三个阶段:
开始事物;以 MULTI 开始一个事物.
命令入队; 多个命令加入事物.
执行事物;由 EXEC 命令触发事物,一并执行事物中的所有命令.

10、缓存穿透
查询一个数据库中不存在的数据，比如商品详情，查询一个不存在的ID，每次都会访问DB，如果有人恶意破坏，很可能直接对DB造成过大地压力
解决方案：当通过某一个key去查询数据的时候，如果对应在数据库中的数据都不存在，我们将此key对应的value设置为一个默认的值，比如“NULL”，并设置一个缓存的失效时间，这时在缓存失效之前，所有通过此key的访问都被缓存挡住了。后面如果此key对应的数据在DB中存在时，缓存失效之后，通过此key再去访问数据，就能拿到新的value了。

11、缓存雪崩
是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。
解决方案：将系统中key的缓存失效时间均匀地错开，防止统一时间点有大量的key对应的缓存失效。比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

12、缓存击穿
redis缓存击穿（热点Key）：缓存中的一个Key(比如一个促销商品)，在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
解决方案：对缓存查询加锁，如果KEY不存在，就加锁，然后查DB入缓存，然后解锁；其他进程如果发现有锁就等待，然后等解锁后返回数据或者进入DB查询

13、分布式锁
先拿setnx来争抢锁，抢到之后，再用expire给锁加一个过期时间防止锁忘记了释放。
如果在setnx之后执行expire之前进程意外crash或者要重启维护了，那会怎么样？
set指令有非常复杂的参数，可以同时把setnx和expire合成一条指令来用

jedis.set(String key, String value, String nx, String expx, int time)，这个set()方法一共有五个形参：

• 第一个为key，我们使用key来当锁，因为key是唯一的。
• 第二个为value，我们传的是requestId，有key作为锁不就够了吗，为什么还要用到value？原因就是我们在上面讲到可靠性时，分布式锁要满足第四个条件解铃还须系铃人，通过给value赋值为requestId，我们就知道这把锁是哪个请求加的了，在解锁的时候就可以有依据。requestId可以使用UUID.randomUUID().toString()方法生成。
• 第三个为nx，这个参数我们填的是NX，意思是SET IF NOTEXIST，即当key不存在时，我们进行set操作；若key已经存在，则不做任何操作；
• 第四个为expx，这个参数我们传的是PX，意思是我们要给这个key加一个过期的设置，具体时间由第五个参数决定。
• 第五个为time，与第四个参数相呼应，代表key的过期时间。

总的来说，执行上面的set()方法就只会导致两种结果：1. 当前没有锁（key不存在），那么就进行加锁操作，并对锁设置个有效期，同时value表示加锁的客户端。2. 已有锁存在，不做任何操作。

14、Redis同步机制
Redis可以使用主从同步，从从同步。第一次同步时，主节点做一次bgsave，并同时将后续修改操作记录到内存buffer，待完成后将rdb文件全量同步到复制节点，复制节点接受完成后将rdb镜像加载到内存。加载完成后，再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。

15、Redis哨兵机制
Redis的哨兵(sentinel) 系统用于管理多个 Redis 服务器,该系统执行以下三个任务:

监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。

提醒(Notification):当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移(Automatic failover):当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。

每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown).若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置。

虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel)。
哨兵(sentinel) 的一些设计思路和zookeeper非常类似

哨兵(Sentinel)总结

1、Sentinel的作用：

• A、Master 状态监测
• B、如果Master 异常，则会进行Master-slave转换，将其中一个Slave作为Master，将之前的Master作为Slave
• C、Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

2、Sentinel的工作方式:

• 1)：每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令。
• 2)：如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。
• 3)：如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
• 4)：当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态，
  则Master会被标记为客观下线 。
• 5)：在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 。
• 6)：当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO
  命令的频率会从 10 秒一次改为每秒一次 。
• 7)：若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。
• 若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

Memcached
Memcached是danga.com（运营LiveJournal的技术团队）开发的一套分布式内存对象缓存系统，用于在动态系统中减少数据库负载，提升性能。关于这个东西，相信很多人都用过，本文意在通过对memcached的实现及代码分析，获得对这个出色的开源软件更深入的了解，并可以根据我们的需要对其进行更进一步的优化。末了将通过对BSM_Memcache扩展的分析，加深对memcached的使用方式理解。
本文的部分内容可能需要比较好的数学基础作为辅助。
◎Memcached是什么
在阐述这个问题之前，我们首先要清楚它“不是什么”。很多人把它当作和SharedMemory那种形式的存储载体来使用，虽然memcached使用了同样的“Key=>Value”方式组织数据，但是它和共享内存、APC等本地缓存有非常大的区别。Memcached是分布式的，也就是说它不是本地的。它基于网络连接（当然它也可以使用localhost）方式完成服务，本身它是一个独立于应用的程序或守护进程（Daemon方式）。
Memcached使用libevent库实现网络连接服务，理论上可以处理无限多的连接，但是它和Apache不同，它更多的时候是面向稳定的持续连接的，所以它实际的并发能力是有限制的。在保守情况下memcached的最大同时连接数为200，这和Linux线程能力有关系，这个数值是可以调整的。关于libevent可以参考相关文档。 Memcached内存使用方式也和APC不同。APC是基于共享内存和MMAP的，memcachd有自己的内存分配算法和管理方式，它和共享内存没有关系，也没有共享内存的限制，通常情况下，每个memcached进程可以管理2GB的内存空间，如果需要更多的空间，可以增加进程数。
◎Memcached适合什么场合
在很多时候，memcached都被滥用了，这当然少不了对它的抱怨。我经常在论坛上看见有人发贴，类似于“如何提高效率”，回复是“用memcached”，至于怎么用，用在哪里，用来干什么一句没有。memcached不是万能的，它也不是适用在所有场合。
Memcached是“分布式”的内存对象缓存系统，那么就是说，那些不需要“分布”的，不需要共享的，或者干脆规模小到只有一台服务器的应用，memcached不会带来任何好处，相反还会拖慢系统效率，因为网络连接同样需要资源，即使是UNIX本地连接也一样。 在我之前的测试数据中显示，memcached本地读写速度要比直接PHP内存数组慢几十倍，而APC、共享内存方式都和直接数组差不多。可见，如果只是本地级缓存，使用memcached是非常不划算的。
Memcached在很多时候都是作为数据库前端cache使用的。因为它比数据库少了很多SQL解析、磁盘操作等开销，而且它是使用内存来管理数据的，所以它可以提供比直接读取数据库更好的性能，在大型系统中，访问同样的数据是很频繁的，memcached可以大大降低数据库压力，使系统执行效率提升。另外，memcached也经常作为服务器之间数据共享的存储媒介，例如在SSO系统中保存系统单点登陆状态的数据就可以保存在memcached中，被多个应用共享。
需要注意的是，memcached使用内存管理数据，所以它是易失的，当服务器重启，或者memcached进程中止，数据便会丢失，所以memcached不能用来持久保存数据。很多人的错误理解，memcached的性能非常好，好到了内存和硬盘的对比程度，其实memcached使用内存并不会得到成百上千的读写速度提高，它的实际瓶颈在于网络连接，它和使用磁盘的数据库系统相比，好处在于它本身非常“轻”，因为没有过多的开销和直接的读写方式，它可以轻松应付非常大的数据交换量，所以经常会出现两条千兆网络带宽都满负荷了，memcached进程本身并不占用多少CPU资源的情况。
◎Memcached的工作方式
以下的部分中，读者最好能准备一份memcached的源代码。
Memcached是传统的网络服务程序，如果启动的时候使用了-d参数，它会以守护进程的方式执行。创建守护进程由daemon.c完成，这个程序只有一个daemon函数，这个函数很简单（如无特殊说明，代码以1.2.1为准）：