redis2

入门： 与其他数据库的对比

http://www.cnblogs.com/jing99/p/6112055.html

• 与Memcached对比总结：

1.数据持久化： 提供持久化功能，重启时加载并使用

2.数据高可用方面： 支持数据备份，即集群的 master-slave模式的数据备份

数据一致性： Memcached提供了cas命令，可以保证多个并发访问操作同一份数据的一致性问题。 Redis没有提供cas 命令，并不能保证这点，不过Redis提供了事务的功能，可以保证一串 命令的原子性，中间不会被任何操作打断

4.存储方式及其它方面 　　Memcached基本只支持简单的key-value存储，不支持枚举，不支持持久化和复制等功能 　　Redis除key/value之外，还支持list,set,sorted set,hash等众多数据结构，提供了KEYS 　　进行枚举操作，但不能在线上使用，如果需要枚举线上数据，Redis提供了工具可以直接扫描其dump文件，枚举出所有数据，Redis还同时提供了持久化和复制等功能

3.内存数据管理方面： redis并不是所有的数据一直保存在内存中： Redis只会缓存所有的 key的信息，如果Redis发现内存的使用量超过了某一个阀值，将触发swap的操作，Redis根据“swappability = age*log(sizeinmemory)”计 算出哪些key对应的value需要swap到磁盘。然后再将这些key对应的value持久化到磁盘中，同时在内存中清除。这种特性使得Redis可以 保持超过其机器本身内存大小的数据。当然，机器本身的内存必须要能够保持所有的key，毕竟这些数据是不会进行swap操作的。同时由于Redis将内存 中的数据swap到磁盘中的时候，提供服务的主线程和进行swap操作的子线程会共享这部分内存，所以如果更新需要swap的数据，Redis将阻塞这个 操作，直到子线程完成swap操作后才可以进行修改

当 从Redis中读取数据的时候，如果读取的key对应的value不在内存中，那么Redis就需要从swap文件中加载相应数据，然后再返回给请求方。 这里就存在一个I/O线程池的问题。在默认的情况下，Redis会出现阻塞，即完成所有的swap文件加载后才会相应。这种策略在客户端的数量较小，进行 批量操作的时候比较合适。但是如果将Redis应用在一个大型的网站应用程序中，这显然是无法满足大并发的情况的。所以Redis运行我们设置I/O线程 池的大小，对需要从swap文件中加载相应数据的读取请求进行并发操作，减少阻塞的时间

4.Memcached是多线程，非阻塞IO复用的网络模型，分为监听主线程和worker子线程； Redis使用单线程的IO复用模型，自己封装了一个简单的AeEvent事件处理框架，主要实现了epoll、kqueue和select，对于单纯只有IO操作来说，单线程可以将速度优势发挥到最大，但是Redis也提供了一些简单的计算功能，比如排序、聚合等，对于这些操作，单线程模型实际会严重影响整体吞吐量，CPU计算过程中，整个IO调度都是被阻塞住的

5.内存管理方面： Memcached使用预分配的内存池的方式，使用slab和大小不同的chunk来管理内存，Item根据大小选择合适的chunk存储，内存池的方式可以省去申请/释放内存的开销，并且能减小内存碎片产生，但这种方式也会带来一定程度上的空间浪费

Redis使用现场申请内存的方式来存储数据，并且很少使用free-list等方式来优化内存分配，会在一定程度上存在内存碎片，Redis跟据存储命令参数，会把带过期时间的数据单独存放在一起，并把它们称为临时数据，非临时数据是永远不会被剔除的，即便物理内存不够，导致swap也不会剔除任何非临时数据(但会尝试剔除部分临时数据)，这点上Redis更适合作为存储而不是cache

5.关于不同语言的客户端支持 　　在不同语言的客户端方面，Memcached和Redis都有丰富的第三方客户端可供选择，不过因为Memcached发展的时间更久一些，目前看在客户端支持方面，Memcached的很多客户端更加成熟稳定，而Redis由于其协议本身就比Memcached复杂，加上作者不断增加新的功能等，对应第三方客户端跟进速度可能会赶不上，有时可能需要自己在第三方客户端基础上做些修改才能更好的使用。 　　根据以上比较不难看出，当我们不希望数据被踢出，或者需要除key/value之外的更多数据类型时，或者需要落地功能时，使用Redis比使用Memcached更合适

　　总结： 　　1.Redis使用最佳方式是全部数据in-memory。 　　2.Redis更多场景是作为Memcached的替代者来使用。 　　3.当需要除key/value之外的更多数据类型支持时，使用Redis更合适。 　　4.当存储的数据不能被剔除时，使用Redis更合适

1）性能对比：由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis最近也在存储大数据的性能上进行优化，但是比起Memcached，还是稍有逊色。 2）内存使用效率对比：使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。 3）Redis支持服务器端的数据操作：Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作，通常在Memcached里，你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。所以，如果需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择

• redis K,V K:String 其中V有多种数据结构：如字符串（Strings），散列（Hashes），列表（Lists），集合（Sets），有序集合（Sorted Sets或者是ZSet） 与范围查询， Bitmaps，Hyperloglogs 和 地理空间（Geospatial）索引半径查询。 其中常见的数据结构类型有String、List、Set、Hash、ZSet这5种， （redis 中文官方论坛： http://redis.cn/commands.html 应用尽有）

数据库：单机

• 过期健删除策略：

• 定时删除 含义：在设置key的过期时间的同时，为该key创建一个定时器，让定时器在key的过期时间来临时，对key进行删除
• 优点：保证内存被尽快释放
• 缺点： 若过期key很多，删除这些key会占用很多的CPU时间，在CPU时间紧张的情况下，CPU不能把所有的时间用来做要紧的事儿，还需要去花时间删除这些key 定时器的创建耗时，若为每一个设置过期时间的key创建一个定时器（将会有大量的定时器产生），性能影响严重 没人用
• 惰性删除 含义：key过期的时候不删除，每次从数据库获取key的时候去检查是否过期，若过期，则删除，返回null。
• 优点：删除操作只发生在从数据库取出key的时候发生，而且只删除当前key，所以对CPU时间的占用是比较少的，而且此时的删除是已经到了非做不可的地步（如果此时还不删除的话，我们就会获取到了已经过期的key了）
• 缺点：若大量的key在超出超时时间后，很久一段时间内，都没有被获取过，那么可能发生内存泄露（无用的垃圾占用了大量的内存）
• 定期删除 含义：每隔一段时间执行一次删除过期key操作
• 优点： 通过限制删除操作的时长和频率，来减少删除操作对CPU时间的占用--处理"定时删除"的缺点 定期删除过期key--处理"惰性删除"的缺点
• 缺点 在内存友好方面，不如"定时删除" 在CPU时间友好方面，不如"惰性删除"
• 难点： 合理设置删除操作的执行时长（每次删除执行多长时间）和执行频率（每隔多长时间做一次删除）（这个要根据服务器运行情况来定了，一般对于可以容忍1秒丢失的数据，用定期删除）

• AOF,RDB和复制功能对过期键的处理 
• 发布订阅等

Redis集群

• redis提供4种集群方案

1. 主备：天生支持，但是只提供数据备份，主从复制在极端情况时会存在数据丢失。
2. 主备+哨兵：很好，能自动识别，自动切换。但是哨兵 不是高可用
3. 多个主备+哨兵集群 解决上面的哨兵非高可用，在低版本的Redis当中 这是最好的方式 客户端分片 http://blog.csdn.net/u012477338/article/details/51719309
4. 3 以后 服务器端Cluster
5. 客户端与服务端分片的区别 

Redis 分布式锁

Redis 购物车

Redis 做系统缓存 高并发方案

• 举例场景 库存扣减
• 流量小： 排队+完全相信缓存
• 流量较大 :前端限流+一致性hash路由+乐观锁+减少事务块大小+延迟持久化

收集的一些博文：

基于redis的 分布式锁 (参考。 建议用 redisson) http://blog.csdn.net/ugg/article/details/41894947 http://www.cnblogs.com/0201zcr/p/5942748.html java分布式锁多种方法比对 http://www.sohu.com/a/113038230_229822

秒杀抢购 http://www.cnblogs.com/longtaosoft/p/6627568.html

缓存击穿，穿透，雪崩 解决方案 http://mp.weixin.qq.com/s/TBCEwLVAXdsTszRVpXhVug 通过 redis 和 kafka 服务器做 本地缓存在 缓存失效是，通过kafka做更新 http://blog.csdn.net/zeb_perfect/article/details/54135506

防止雪崩 熔断器Hystrix做熔断器和服务降级 https://segmentfault.com/a/1190000005988895

业务层缓存 通过后台定时任务 不断预热 热点数据