Redis是一个开源、高性能、基于键值对的缓存与存储系统。
劣势:Redis是单线程,Memcached是多线程,在多核服务器上后者的性能理论上会更高一些。 优点:随着Redis3.0的推出,标志着memcache的全部功能都已经成了Redis的子集。同时Redis对集群的支持使得Memcache原有的第三方集群工具再也不成为优点。所以,在新项目中使用Redis替代Memcache将会是很是好的选择。
(1)字符串类型(Key-Value 使用最多的类型 (2)散列类型(Hash)适合存储对象 (3)列表类型(List) (4)集合类型(Set) (5)有序集合类型(Zset)
内存
Remote Dictionary Server(远程数据服务)
共六种数据淘汰策略。(分三类) 1、从已设置过时的数据集 一、volatile-lru:从已设置过时时间的数据集中,选择最近最少使用的数据淘汰 二、volatile-ttl:从已设置过时时间的数据集中,选择将要过时的数据淘汰 三、volatile-random:从已设置过时时间的数据集中,任意选择数据淘汰 2、从总体数据集 四、allkeys-lru:从全数据集中,选择最近最少使用的数据淘汰 五、allkeys-random:从全数据集中任意选择数据淘汰 3、驱逐(默认策略-直接返回错误) 六、noenviction(驱逐):不删除任意数据(但redis还会根据引用计数器进行释放),这时若是内存不够时,会直接返回错误
目前Linux版本已经至关稳定,用户量很大,无需开发windows版本,反而会带来兼容性等问题。
512M。
内存存取远比磁盘IO快得多。
一、Twemproxy,推特的开源方案。它会以一个代理的身份接收请求并使用一致性hash算法,将请求转接到具体redis,将结果再返回twemproxy。 问题:redis节点数量改变时候,数据没法自动移动到新的节点。 二、Codis,豌豆荚的开源方案。目前使用最多的集群方案,基本和twemproxy一致的效果,它支持在 节点数量改变状况下,旧节点数据可恢复到新hash节点。 三、Redis cluster3.0自带的集群,特色:他的分布式算法不是一致性hash,而是hash槽,以及自身支持节点设置从节点。 四、业务代码层实现,在代码层,对key 进行hash计算,而后去对应的redis实例操做数据。 这种方式对hash层代码要求比较高,须要重点考虑的是,节点失效后的替代算法方案,数据震荡后的自动脚本恢复,实例的监控,等等。
有A,B,C三个节点的集群,在没有复制模型的状况下,若是节点B失败了,那么整个集群就会由于缺乏5501-11000这个范围的槽而不可用。数据丢失
先计算下这20W条数据占用的内存,设置最大可用内存,当内存中的数据集达到上限时,redis就会启动LRU(数据淘汰策略)。
一、会话缓存(Session Cache) 例如:分布式登陆信息,购物车信息,能提供持久化。 二、全页缓存(FPC) 除基本的会话token以外,Redis还提供很简便的FPC平台。即便重启了Redis实例,由于有磁盘的持久化,用户也不会看到页面加载速度的降低 三、队列 因为支持 list 和 set 操做,这使得Redis能做为一个很好的消息队列平台来使用 四、排行榜/计数器 incr range 五、发布/订阅
Redisson、Jedis等等,官方推荐使用Redisson。
Redisson 是一个高级的、分布式协调Redis客户端。
一、Jedis是Redis的Java实现的客户端,其API提供了比较全面的Redis命令的支持; 二、Redisson实现了分布式和可扩展的Java数据结构,和Jedis相比,功能较为简单,不支持字符串操做,不支持排序、事务、管道、分区等Redis特性。 三、Redisson的宗旨是促进使用者对Redis的关注分离,从而让使用者可以将精力更集中地放在处理业务逻辑上。
设置密码:两种方式 需重启redis: 打开redis.conf中的 requirepass foobared 不重启redis: config set requirepass 123456 验证密码:两种方式 方式1、登陆的时候验证 例如:redis-cli -h 127.0.0.1 -p 6379 -a cfadata@2016 方式2、登陆时不指定密码,而在执行操做前进行认证。使用auth 命令认证。
一、Redis 集群中内置了 16384 个哈希槽。 二、须要在 Redis 集群中存一个 key-value时,Redis 先对 key 使用 crc16 算法算出一个结果。 三、而后把结果对 16384 取模,这样每一个 key 都会对应一个编号在 0-16383 之间的哈希槽。 四、Redis 会根据节点数量大体均等的将哈希槽映射到不一样的节点。
为了使在部分节点失败或者大部分节点没法通讯的状况下集群仍然可用,因此集群使用了主从复制模型,每一个节点都会有N-1个复制品
Redis并不能保证数据的强一致性,这意味这在实际中集群在特定的条件下(使用的内存超过了最大可用内存(数据淘汰策略是noenviction(驱逐)的时候))可能会丢失写操做。
异步复制 初始化复制: 一、从数据库启动后,会向主数据库发送SYNC命令。 二、主数据库收到SYNC后会在后台保存快照(RDB持久化过程),并将保存快照期间接收到的命令缓存起来。 三、快照完成后,Redis会将快照文件和全部缓存的命令发送给从数据库。 四、从数据库收到快照后会载入快照文件并执行缓存命令。 运行中复制: 当主数据库每当收到写命令,就会将命令同步到从数据库。 断线重连机制: redis2.6以前,断线重连后会进行所有复制(主数据库的RDB文件发给从数据库) redis2.8以后,断线重连后进行的是增量复制。
16384个,可是建议最多有1000个节点。
默认在0号数据库。
ping命令测试客户端与Redis服务链接是否正常,返回pong正常。
能够在服务端未响应时,客户端能够继续向服务端发送请求,并最终一次性读取全部服务端的响应。
一、提供了命令打包,顺序执行的机制。 二、命令入队,先进先出。 三、带 WATCH 命令的事务,当键对应的值被修改时,事务直接返回失败,不然成功。 四、保证了一致性和隔离性,不保证原子性和持久性(Redis的事务不是一个完整的事务)。 参考: 深刻理解Redis事务
一、MULTI (开启事务) 二、DISCARD (取消事务,若是正在使用 WATCH 命令监视某个(或某些) key,那么取消全部监视,等同于执行命令 UNWATCH) 三、EXEC (执行事务) 四、WATCH (监视一个(或多个) key ,若是在事务执行以前这个(或这些) key 被其余命令所改动,那么事务将被打断)
一、过时时间:set key timeout value 二、永久有效:默认不设置过时时间(set key value)永久有效,可是若是实际使用内存超过你设置的最大内存,而且设置了数据淘汰策略,就会使用LRU删除机制
应使用散列表(HashSst),适合存储对象类型。尽量的将数据模型抽象到一个散列表里面。好比:用户对象,不要为这个用户的名称,姓氏,邮箱,密码设置单独的key,而是应该把这个用户的全部信息存储到一张散列表里面。
一、客户端接收到数据写入请求后,Redis检查内存使用状况,若是大于maxmemory的限制, 则根据设定好的策略进行回收。一个新的命令被执行。 二、因此咱们不断地穿越内存限制的边界,经过不断达到边界而后不断地回收回到边界如下。
LRU算法。
Redis2.6开始redis-cli支持一种新的被称之为pipe mode的新模式用于执行大量数据插入。
分区使得咱们原本受限于单台计算机硬件资源的问题再也不是问题,存储不够,计算资源不够,带宽不够,咱们均可以经过增长机器来解决这些问题。
一、客户端分区:就是在客户端就已经决定数据会被存储到哪一个redis节点或者从哪一个redis节点读取。大多数客户端已经实现了客户端分区。 二、代理分区 :意味着客户端将请求发送给代理,而后代理决定去哪一个节点写数据或者读数据。代理根据分区规则决定请求哪些Redis实例,而后根据Redis的响应结果返回给客户端。redis和memcached的一种代理实现就是Twemproxy 三、查询路由(Query routing) :意思是客户端随机地请求任意一个redis实例,而后由Redis将请求转发给正确的Redis节点。Redis Cluster实现了一种混合形式的查询路由,但并非直接将请求从一个redis节点转发到另外一个redis节点,而是在客户端的帮助下直接redirected到正确的redis节点。
一、多键操做是不被支持的,好比咱们将要批量操做的键被映射到了不一样的Redis实例中。 二、多键的Redis事务是不被支持的。 三、分区的最小粒度是键,所以咱们不能将关联到一个键的很大的数据集映射到不一样的实例。 四、当应用分区的时候,数据的处理是很是复杂的,好比咱们须要处理多个rdb/aof文件,将分布在不一样实例的文件汇集到一块儿备份。 五、添加和删除机器是很复杂的,例如Redis集群支持几乎运行时透明的由于增长或减小机器而须要作的rebalancing,然而像客户端和代理分区这种方式是不支持这种功能的。
一、若是Redis被当作缓存使用,使用一致性哈希实现动态扩容缩容。 二、若是Redis被当作一个持久化存储使用,必须使用固定的keys-to-nodes映射关系,节点的数量一旦肯定不能变化。不然的话(即Redis节点须要动态变化的状况),必须使用能够在运行时进行数据再平衡的一套系统,而当前只有Redis集群能够作到这样。
一、一开始就作分区,迁移redis实例不用考虑分区 二、既然Redis是如此的轻量(单实例只使用1M内存),为防止之后的扩容,最好的办法就是一开始就启动较多实例。即使你只有一台服务器,你也能够一开始就让Redis以分布式的方式运行,使用分区,在同一台服务器上启动多个实例。 这样的话,当你的数据不断增加,须要更多的Redis服务器时,你须要作的就是仅仅将Redis实例从一台服务迁移到另一台服务器而已(而不用考虑从新分区的问题)。一旦你添加了另外一台服务器,你须要将你一半的Redis实例从第一台机器迁移到第二台机器。
Twemproxy 是一个Twitter开源的一个redis和memcache快速/轻量级代理服务器;能够将其后端的多台redis或memcached实例进行统一管理与分配,使应用程序只须要在Twemproxy 上进行操做,而不用关心后面具体有多少个真实的redis或memcached存储。
Redis-rb、Predis等。
一、Redis有复杂的数据结构而且提供对他们的原子性操做。 二、Redis的数据类型都是基本数据结构的同时对程序员透明,无需进行额外的抽象。 三、Redis运行在内存中可是能够持久化到磁盘。 四、相同复杂的数据结构,在内存中操做比在磁盘操做更简单。 五、磁盘格式方面是紧凑的以追加的方式产生的,并不须要进行随机访问。
利用Hash,List,Set,Sorted set(zset) 等集合类型数据,由于一般状况下不少小的Key-Value能够用更紧凑的方式存放到一块儿。
INFO
一、默认:若是达到设置的上限,写命令会返回错误信息(可是读命令还能够正常返回) 二、配置淘汰机制:当Redis达到可用内存上限时会冲刷掉旧的数据。
一、能够在同一个服务器部署多个Redis的实例,并把他们看成不一样的服务器来使用。 二、若是你想使用多个CPU,你能够考虑一下分片(shard)。
理论上Redis能够处理2的32次方keys,任何list、set、和sorted set均可以放2的32次方个元素。
一、 Master最好不要作任何持久化工做,如RDB内存快照和AOF日志文件 二、若是数据比较重要,某个Slave开启AOF备份数据,策略设置为每秒同步一次 三、为了主从复制的速度和链接的稳定性,Master和Slave最好在同一个局域网内 四、避免在压力很大的主库上增长从库 五、主从复制不要用网状结构(相似n-1结构),用单向链表结构更为稳定,即:Master <- Slave1 <- Slave2 <- Slave3...这样的结构方便解决单点故障问题,实现Slave对Master的替换。若是Master挂了,能够马上启用Slave1作Master,其余不变。
提供了两种持久化方式:AOF和RDB 区别是: AOF:append only file aof是将Redis执行的每一条命令追加到硬盘文件中(保存的执行命令) RDB:rdb是经过快照的方式将符合条件的数据持久化到硬盘(保存的是命令执行后获得的数据) 持久化配置规则: save 900 20 (意思是900秒内 有超过20条数据写入或修改,就会执行持久化操做)
一、若是想达到足以媲美PostgreSQL的数据安全性, 你应该同时使用两种持久化功能。 二、若是很是关心数据, 但仍然能够承受数分钟之内的数据丢失,那么能够只使用RDB持久化。 三、有不少用户都只使用AOF持久化,但并不推荐这种方式:由于定时生成RDB快照(snapshot)很是便于进行数据库备份, 而且 RDB 恢复数据集的速度也要比AOF恢复的速度要快。
Config Set 命令能够动态地调整 Redis 服务器的配置而无须重启。
一、根据配置规则进行自动快照。 二、用户执行save或者bgsave命令。 三、执行flushall命令。 四、执行复制(replication)时。
一、什么是缓存击穿? 查询一个在缓存中必然不存在的数据,致使每次请求都要在数据库中查询。 二、没缓存和没有缓存的的系统吞吐量有多大的差异? 没有用缓存时,mysql的并发数在300(机械硬盘)-700(固态硬盘)之间(高性能服务器)。通常的笔记本200个链接都撑不住。
一、对空值也作缓存,过时时间设置较短 二、对不符合规则的查询值作过滤 三、用bitMap和布隆过滤器 四、设置KEY为不一样的过时时间 缓存失效: 产生缘由:设置缓存失效的时间过于集中,致使缓存在同一时刻大面积失效。 解决办法:能够为不一样的key设置为不一样的过时时间。 缓存穿透: 产生缘由:查询一个在缓存中必然不存在的数据,致使每次请求都要在数据库中查询。 解决办法:一、对不符合规则的查询值作过滤 二、用bitMap和布隆过滤器 三、空值也作缓存 缓存雪崩: 产生缘由:缓存雪崩就是指因为缓存的缘由,致使大量请求到达后端数据库,从而致使数据库崩溃,整个系统崩溃,发生灾难。“缓存并发”,“缓存穿透”,“缓存颠簸”等问题,其实均可能会致使缓存雪崩现象发生。 解决办法:从应用架构角度,咱们能够经过限流、降级、熔断等手段来下降影响,也能够经过多级缓存来避免这种灾难。
链接:如何搭建高可用的redis服务 (Redis高可用架构的演变)
一、数据结构简单 二、单线程无CPU切换性能损耗 三、没有多线程加锁问题
线程安全的。(单线程没有线程安全一说)
缓存一致性问题 缓存并发 缓存颠簸问题 缓存失效 缓存穿透 缓存的雪崩现象 缓存无底洞现象
。。。
四种实现方式: 一、推特的开源框架 twemproxy 代理 二、豌豆荚的 codis 代理 旧的数据能够映射到新的节点 三、Redis自带的集权 Redis cluster3.0 使用的是hash槽 四、代码层面实现 注意数据震荡后的数据恢复 寻址方式:
原文出处:https://www.cnblogs.com/luao/p/10505273.htmlhtml