本文目录
redis如何处理客户端的连接
连接的建立
Redis 通过监听一个 TCP 端口或者 Unix socket 的方式来接收来自客户端的连接，当一个连接建立后，Redis 内部会进行以下一些操作：
- 首先，客户端 socket 会被设置为非阻塞模式，因为 Redis 在网络事件处理上采用的是非阻塞多路复用模型。
- 然后为这个socket 设置 TCP_NODELAY 属性，禁用 Nagle 算法
- 然后创建一个 readable 的文件事件用于监听这个客户端 socket 的数据发送
当客户端连接被初始化后，Redis 会查看目前的连接数，然后对比配置好的 maxclients 值，如果目前连接数已经达到最大连接数 maxclients 了，那么说明这个连接不能再接收，Redis 会直接返回客户端一个连接错误，并马上关闭掉这个连接。
服务端处理顺序
如果有多个客户端连接上 Redis，并且都向 Redis 发送命令，那么 Redis 服务端会先处理哪个客户端的请求呢？答案其实并不确定，主要与两个因素有关，一是客户端对应的 socket 对应的数字的大小，二是 kernal 报告各个客户端事件的先后顺序。
Redis 处理一个客户端传来数据的步骤如下：
- 它对触发事件的 socket 调用一次 read()，只读一次（而不是把这个 socket 上的消息读完为止），是为了防止由于某个别客户端持续发送太多命令，导致其它客户端的请求长时间得不到处理的情况。
- 当然，当这一次 read() 调用完成后，它里面无论包含多少个命令，都会被一次性顺序地执行。这样就保证了对各个客户端命令的公平对待。
关于最大连接数 maxclients
在 Redis2.4 中，最大连接数是被直接硬编码在代码里面的，而在2.6版本中这个值变成可配置的。maxclients 的默认值是 10000，你也可以在 redis.conf 中对这个值进行修改。
当然，这个值只是 Redis 一厢情愿的值，Redis 还会照顾到系统本身对进程使用的文件描述符数量的限制。在启动时 Redis 会检查系统的 soft limit，以查看打开文件描述符的个数上限。如果系统设置的数字，小于咱们希望的最大连接数加32，那么这个 maxclients 的设置将不起作用，Redis 会按系统要求的来设置这个值。（加32是因为 Redis 内部会使用最多32个文件描述符，所以连接能使用的相当于所有能用的描述符号减32）。
当上面说的这种情况发生时（maxclients 设置后不起作用的情况），Redis 的启动过程中将会有相应的日志记录。比如下面命令希望设置最大客户端数量为100000，所以 Redis 需要 100000+32 个文件描述符，而系统的最大文件描述符号设置为10144，所以 Redis 只能将 maxclients 设置为 10144 – 32 = 10112。
$ ./redis-server --maxclients 100000 23 Jan 11:28:33.179 # Unable to set the max number of files limit to 100032 (Invalid argument), setting the max clients configuration to 10112.
所以说当你想设置 maxclients 值时，最好顺便修改一下你的系统设置，当然，养成看日志的好习惯也能发现这个问题。
具体的设置方法就看你个人的需求了，你可以只修改此次会话的限制，也可以直接通过sysctl 修改系统的默认设置。如：
ulimit -Sn 100000 # This will only work if hard limit is big enough.sysctl -w fs.file-max=100000
输出缓冲区大小限制
对于 Redis 的输出（也就是命令的返回值）来说，其大小经常是不可控的，可能是一个简单的命令，能够产生体积庞大的返回数据。另外也有可能因为执行命令太多，产生的返回数据的速率超过了往客户端发送的速率，这时也会产生消息堆积，从而造成输出缓冲区越来越大，占用过多内存，甚至导致系统崩溃。
所以 Redis 设置了一些保护机制来避免这种情况的出现，这些机制作用于不同种类的客户端，有不同的输出缓冲区大小限制，限制方式有两种：
- 一种是大小限制，当某一个客户端的缓冲区超过某一大小时，直接关闭掉这个客户端连接
- 另一种是当某一个客户端的缓冲区持续一段时间占用空间过大时，也直接关闭掉客户端连接
对于不同客户端的策略如下：
- 对普通客户端来说，限制为0，也就是不限制，因为普通客户端通常采用阻塞式的消息应答模式，如：发送请求，等待返回，再发请求，再等待返回。这种模式通常不会导致输出缓冲区的堆积膨胀。
- 对于 Pub/Sub 客户端来说，大小限制是32m，当输出缓冲区超过32m时，会关闭连接。持续性限制是，当客户端缓冲区大小持续60秒超过8m，也会导致连接关闭。
- 而对于 Slave 客户端来说，大小限制是256m，持续性限制是当客户端缓冲区大小持续60秒超过64m时，关闭连接。
上面三种规则都是可配置的。可以通过 CONFIG SET 命令或者修改 redis.conf 文件来配置。
输入缓冲区大小限制
Redis 对输入缓冲区大小的限制比较暴力，当客户端传输的请求大小超过1G时，服务端会直接关闭连接。这种方式可以有效防止一些客户端或服务端 bug 导致的输入缓冲区过大的问题。
Client 超时
对当前的 Redis 版本来说，服务端默认是不会关闭长期空闲的客户端的。但是你可以修改默认配置来设置你希望的超时时间。比如客户端超过多长时间无交互，就直接关闭。同理，这也可以通过 CONFIG SET 命令或者修改 redis.conf 文件来配置。
值得注意的是，超时时间的设置，只对普通客户端起作用，对 Pub/Sub 客户端来说，长期空闲状态是正常的。
另外，实际的超时时间可能不会像设定的那样精确，这是因为 Redis 并不会采用计时器或者轮训遍历的方法来检测客户端超时，而是通过一种渐近式的方式来完成，每次检查一部分。所以导致的结果就是，可能你设置的超时时间是10s，但是真实执行的时间是超时12s后客户端才被关闭。
CLIENT 命令
Redis 的 CLIENT 命令能够实现三种功能：检查连接的状态，杀掉某个连接以及为连接设置名字。
CLIENT LIST 命令能够获取当前所有客户端的状态，使用方法如下：
redis 127.0.0.1:6379》 client list addr=127.0.0.1:52555 fd=5 name= age=855 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client addr=127.0.0.1:52787 fd=6 name= age=6 idle=5 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping
如上面命令的输出可知，目前此 Redis 有两个客户端连接，每一行表示一个连接的各项信息：
- addr: 客户端的TCP地址，包括IP和端口
- fd: 客户端连接 socket 对应的文件描述符句柄号
- name: 连接的名字，默认为空，可以通过 CLIENT SETNAME 设置
- age: 客户端存活的秒数
- idle: 客户端空闲的秒数
- flags: 客户端的类型 (N 表示普通客户端，更多类型见
Redis是啥
想要了解Redis，先从Redis是什么？为何要用Redis？有哪些特性，以及其集群架构来几个方面来了解。
Redis 简介
Redis 是一个开源（BSD 许可）的、内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。为什么要用 Redis
在高并发场景下，如果需要经常连接结果变动频繁的数据库，会导致数据库读取及存取的速度变慢，数据库压力极大。因此我们需要通过缓存来减少数据库的压力，使得大量的访问进来能够命中缓存，只有少量的需要到数据库层。由于缓存基于内存，可支持的并发量远远大于基于硬盘的数据库。所以对于高并发设计，缓存的设计是必不可少的一环。而 Redis 作为比较热门的内存存储系统之一，由于其对数据持久化的支持，种类丰富的数据结构，使其定位更倾向于内存数据库，适用于对读写效率要求都很高、数据处理业务复杂和对安全性要求较高的系统。Redis 特征
- 单线程，利用 redis 队列技术将访问变为串行访问，消除了传统数据库串行控制的开销。
Redis 的线程模型：- Redis 支持数据的持久化，包括 RDB 的全量持久化，或者 AOF 的增量持久化，从而使得
Redis 挂了，数据是有机会恢复的。也可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。- 分布式架构，读写分离。
- 支持的数据结构丰富。Redis 不仅仅支持简单的 key-value 类型的数据，同时还提供 list、
set、zset、hash 等数据结构的存储。- Redis 支持数据的备份，提供成熟的主备同步，故障切换的功能，从而保证了高可用。
Redis Cluster 架构
Redis 搭建方式有很多种，本章主要介绍 Redis Cluster 集群构建方式：Redis 3.0 之后版本支持 Redis Cluster 集群，Redis Cluster 采用无中心结构，每个节点保存数据和整个集群状态，每个节点都和其他所有节点连接。Redis Cluster 为了保证数据的高可用性，加入了主从模式，一个主节点对应一个或多个从节点，主节点提供数据存取，从节点则是从主节点拉取数据备份，当这个主节点挂掉后，就会有这个从节点选取一个来充当主节点，从而保证集群不会挂掉。主从结构，一是为了纯粹的冗余备份，二是为了提升读性能，比如很消耗性能的 SORT 就可以由从服务器来承担。Redis 的主从同步是异步进行的，这意味着主从同步不会影响主逻辑，也不会降低 redis 的处理性能。主从架构中，可以考虑关闭主服务器的数据持久化功能，只让从服务器进行持久化，这样可以提高主服务器的处理性能。在主从架构中，从服务器通常被设置为只读模式，这样可以避免从服务器的数据被误修改。如何搭建高可用Redis架构
1.要看你的业务复杂度来确定如何搭建。简单的可以采用redis的master-slave构架，实现简单的读高可用，写入不是高可用。
2.可以采用对master采用keepalived监控的方式，来实现master当机时的热切换，redis本身也带了一个master的热备机制
３采用ｒｅｄｉｓ的ｃｌｕｓｔｅｒ方案，实现负载分离与高可用的方式。（这个方案最少需要３台机器，如果集群较小，配置较为方便。网上现在的攻略较多。）
memcache与redis有何区别，redis有哪些优势呢
简介
说到缓存技术，只要有一定经验的开发人员，肯定会想到redis和memcached这两个。并且在BAT里，redis已经逐渐取代了memcached，成为分布式场景广泛使用的缓存方案。接下来，我们就分析下，redis是如何取代memcached，成为开发者的宠儿的。
一、支持的存储类型不同
虽然redis和memcached都是内存型数据库，并且memcached不仅能够存储string类型，还能够存储图片、文件、视频等格式的文件。然而对于更多的使用内存数据库做缓存以及分布式方案的程序开发者来说，memcached提供的string类型存储的应用场景非常有限，而存储图片视频的功能又十分鸡肋（许多公司的用户场景是没这方面需求）。相比之下，redis提供set，hash，list等多种类型的存储结构，非常适合分布式缓存的实现。
二、数据落盘
memcached 数据不可恢复，虽然大多数人使用缓存以及分布式方案都不会要求数据持久化，但是谁也不能保证不出现万一的情况。一旦发生稳定性问题，memcached挂掉后，数据是不可恢复的，而redis除了支持在配置里打开数据落盘（RDB），还能通过aof来找回数据。
三、内存空间与数据量
memcached可以修改最大内存，使用的是LRU算法，而redis目前底层使用了自己的VM，引入了新的特性突破了物理内存的限制。个人认为在这方面依然是redis更加优秀一些。
备注：value值-redis最大可以达到1GB，而memcache只有1MB；
四、使用场景
（1）、会话缓存（Session Cache）
最常用的一种使用Redis的情景是会话缓存（session cache）。用Redis缓存会话比其他存储（如Memcached）的优势在于：Redis提供持久化。当维护一个不是严格要求一致性的缓存时，如果用户的购物车信息全部丢失，大部分人都会不高兴的，现在，他们还会这样吗？
幸运的是，随着 Redis 这些年的改进，很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。
（2）、全页缓存（FPC）
除基本的会话token之外，Redis还提供很简便的FPC平台。回到一致性问题，即使重启了Redis实例，因为有磁盘的持久化，用户也不会看到页面加载速度的下降，这是一个极大改进，类似PHP本地FPC。
再次以Magento为例，Magento提供一个插件来使用Redis作为全页缓存后端。
此外，对WordPress的用户来说，Pantheon有一个非常好的插件 wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。
（3）、队列
Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作，就类似于本地程序语言（如Python）对 list 的 push/pop 操作。
如果你快速的在Google中搜索“Redis queues”，你马上就能找到大量的开源项目，这些项目的目的就是利用Redis创建非常好的后端工具，以满足各种队列需求。例如，Celery有一个后台就是使用Redis作为broker，你可以从这里去查看。
（4），排行榜/计数器
Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（Sorted Set）也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。所以，我们要从排序集合中获取到排名最靠前的10个用户–我们称之为“user_scores”，我们只需要像下面一样执行即可：
当然，这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数，你需要这样执行：
ZRANGE user_scores 0 10 WITHSCORES
Agora Games就是一个很好的例子，用Ruby实现的，它的排行榜就是使用Redis来存储数据的，你可以在这里看到。
（5）、发布/订阅
最后（但肯定不是最不重要的）是Redis的发布/订阅功能。发布/订阅的使用场景确实非常多。我已看见人们在社交网络连接中使用，还可作为基于发布/订阅的脚本触发器，甚至用Redis的发布/订阅功能来建立聊天系统！（不，这是真的，你可以去核实）。
（6）、其他
但是如果是对缓存的数据格式有更多的要求，且对安全性也有很高的要求的话，建议还是使用redis，这也是redis目前正在逐渐代替memcached的根本原因。
五、总结
六、快问快答
1、redis常见性能问题和解决方案？
(1) Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件
(2) 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次
(3) 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内
(4) 尽量避免在压力很大的主库上增加从库
(5) 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master 《- Slave1 《- Slave2 《- Slave3…
这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。
2、MySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据？
相关知识：redis 内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。redis 提供 6种数据淘汰策略：
voltile-lru：从已设置过期时间的数据集（server.db.expires）中挑选最近最少使用的数据淘汰；
volatile-ttl：从已设置过期时间的数据集（server.db.expires）中挑选将要过期的数据淘汰；
volatile-random：从已设置过期时间的数据集（server.db.expires）中任意选择数据淘汰；
allkeys-lru：从数据集（server.db.dict）中挑选最近最少使用的数据淘汰；
allkeys-random：从数据集（server.db.dict）中任意选择数据淘汰
no-enviction（驱逐）：禁止驱逐数据；
七、经典架构
---------------END----------------
后续的内容同样精彩
Java工程师是如何使用Redis的
在分布式和微服务等架构遍地开花的实践中，Redis始终作为分布式缓存的首选，可谓经久不衰、独树一帜。Redis基于内存运行并支持持久化的NoSQL数据库，是当前最热门的NoSql数据库之一，也被人们称为数据结构服务器。
而为何要使用Redis呢？Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。Redis支持master-slave(主-从)模式应用。Redis支持数据持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。Redis单个value的最大限制是1GB，memcached只能保存1MB的数据。基于种种原因，Redis成为我们缓存架构的首选，而我在开启码农生涯时，就接触到Redis，只是当时的使用比较简单。
最开始时，因互联网化团队初建，各种所需要的中间件都需要自己搭建，包含Redis，而我们使用Docker搭建Redis集群，采用主从的Redis架构，再使用Sentinel（哨兵）模式来监控该Redis集群，使用也是通过Sentinel来使用。通过Spring或Spring Boot的哨兵连接方式连接Redis，注册成Bean，然后使用序列化的Key-Value结构来缓存所需要的数据。而因领导的风格原因，我们也仅仅被允许采用Key-Value的基础功能来进行Redis操作。至于其中的原因，也没有深究。
而随后，跳槽到现公司，其将Redis作为基础服务进行封装，而业务团队仅通过加密串即可进行直接连接，其背后的可高用、主从分片、灾备等均由基础架构团队负责。基础架构团队提供的操作方式，就不仅仅限于使用Key-Value的get、set、delete等方法，而几乎完全提供了Redis的所有命令，包含inc、sadd等计数、集合操作。当然，有了这些，对程序员的要求更高，要在合适的场景中选择恰当的命令进行操作，也不是一件容易的事。
或许，使用Redis有这样那样的原因，但在我看来，最重要的就两条：其一，它能提高用户的访问速度，大量的降低系统响应的TP99；其二，它是主流，大家都在用，而且经过了时间的检验，抗住了一个又一个电商大促的业务场景。
作者：夕阳雨晴，欢迎关注我的头条号。偶尔美文，主流Java，为你讲述不一样的码农生活。
