泉源：https://wdxtub.com/2016/07/05/redis-guide/
Redis是C实现的基于内存并可长期的键值对数据库，在分布式服务中常常被用作缓存。除此之外还可以利用其特点做很多风趣的应用，以是我们不但必要会用，更必要明白其工作机制。
Redis的具体先容在官方网站和维基百科都有，这里我们只要记取几个关键词既可：开源、C语言、网络交互、基于内存、可长期化、键值对、数据库。作者是SalvatoreSanfilippo，他的博客和github主页都放到文末的参考链接里，有爱好的同砚可以去看看。
根据Redis主页上的先容，很多公司都在利用Redis，比力闻名的有TwitterGitHubWeiboPinterestSnapchatCraigslistDiggStackOverflowFlickr等等，想要相识更多的话，可以参考WhousesRedis?
也有另一种叫法，称为数据布局服务器，由于生存的value可以是字符串(string)、字典(map)、列表(list)、聚集(sets)或有序聚集(sortedset)。那么键值对存储这么多，到底Redis有什么差别之处呢？一是原子性操纵，二是在内存中运行。
Redis脚本利用Lua表明器来实行脚本。Reids2.6版本通过内嵌支持Lua环境。实行脚本的常用下令为EVAL。根本语法为127.0.0.1:6379EVALnumkeyskey[key...]arg[arg...]
根本利用
安装
在Mac下的安装非常简单，只必要brewinstallredis即可，假如必要开机启动，按照安装完成后的提示输出一条下令即可。然后我们输入redis-server应该就能看到如下信息
我们看到如今Redis运行在standalone模式（相对于分布式），对应的端口是6379。至于为什么是6379，这背后是有故事的，原文在这里https://oldblog.antirez.com/post/redis-as-LRU-cache.html（打开之后搜刮6379），我扼要翻译一下：
6379是MERZ这个单词在九宫格输入时的按键次序，那么题目来了，MERZ又是什么鬼？简单来说来自于一个意大利showgirl，名字叫做AlessiaMerz，图片这里就不放了。作者一样平常生存中会创造一些『俚语』，merz这个词已经用了十年，意思也不停在变革。早先他们merz来表现很蠢的事变，比方说『Hey,that’smerz!』，之后意思有些变革，指的是那些有肯定技能含量但没什么意义而且还很蠢(stupid)的事儿，大概是那些必要大量技能和耐烦才华完成但仍旧很蠢(stupid)的事儿（看出来了吗，核心是Stupid）。作者举了两个例子，比方说用一台GPS和一辆破车泰半夜为制作3D舆图采样，大概在明知道本身不会去买彩票的环境下还是研究大量的彩票信息来找到其『不随机』的证据。总结一下就是有hackvalue的事变，大概是那些为了hackvalue而去办事的人。于是天然而然的，merz在拨号键盘上对应的数字就成为了Redis的端标语。
除了前面利用过的redis-server下令，我们还可以利用redis-cli下令来启动redis客户端，比如：
假如必要在长途Redis上实行下令，也可以用redis-cli下令，具体的方式为redis-cli-hhost-pport-apassword
毗连
根本下令有5个，可以覆盖一样平常利用的大部分场景，比方说心跳检测、切换数据库之类的：
AUTHpassword:验证暗码
ECHOmessage:打印字符串
PING:查察服务是否在运行，假如在运行，就输出PONG
QUIT:关闭当前毗连
SELECTindex:选择指定的数据库
状态
我们可以利用INFO下令来相识当前Redis数据库的根本状态，更多的下令请查阅参考链接中给出的地点，这里不赘述：
设置
Redis的设置文件可以在安装目次下找到，名为redis.conf，我们来看看都有什么设置
具体表明
Redis默认不是以保卫进程的方式运行，可以通过该设置项修改，利用yes启用保卫进程daemonizeno
当Redis以保卫进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定pidfile/var/run/redis.pid
指定Redis监听端口，默认端口为6379port6379
绑定的主机地点bind127.0.0.1
当客户端闲置多长时间后关闭毗连，假如指定为0，表现关闭该功能timeout300
指定日记记录级别，Redis统共支持四个级别：debug、verbose、notice、warning，默以为verbose,loglevelverbose
日记记录方式，默以为标准输出，假如设置Redis为保卫进程方式运行，而这里又设置为日记记录方式为标准输出，则日记将会发送给/dev/null,logfilestdout
设置数据库的数量，默认数据库为0，可以利用SELECTdbid下令在毗连上指定命据库id,databases16
指定在多长时间内，有多少次更新操纵，就将数据同步到数据文件，可以多个条件共同savesecondschangesRedis默认设置文件中提供了三个条件：save9001,save30010,save6010000,分别表现900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改。
指定存储至本地数据库时是否压缩数据，默以为yes，Redis采取LZF压缩，假如为了节流CPU时间，可以关闭该选项，但会导致数据库文件变的巨大rdbcompressionyes
指定本地数据库文件名，默认值为dump.rdb,dbfilenamedump.rdb
指定本地数据库存放目次dir./
设置当本机为slave服务时，设置master服务的IP地点及端口，在Redis启动时，它会主动从master举行数据同步slaveofmasteripmasterport
当master服务设置了暗码掩护时，slave服务毗连master的暗码masterauthmaster-password
设置Redis毗连暗码，假如设置了毗连暗码，客户端在毗连Redis时必要通过AUTHpassword下令提供暗码，默认关闭requirepassfoobared
设置同一时间最大客户端毗连数，默认无穷制，Redis可以同时打开的客户端毗连数为Redis进程可以打开的最大文件形貌符数，假如设置maxclients0，表现不作限定。当客户端毗连数到达限定时，Redis会关闭新的毗连并向客户端返回maxnumberofclientsreached错误信息maxclients128
指定Redis最大内存限定，Redis在启动时会把数据加载到内存中，到达最大内存后，Redis会先实行打扫已到期或即将到期的Key，当此方法处理惩罚后，仍旧到达最大内存设置，将无法再举行写入操纵，但仍旧可以举行读取操纵。Redis新的vm机制，会把Key存放内存，Value会存放在swap区,maxmemorybytes
指定是否在每次更新操纵后举行日记记录，Redis在默认环境下是异步的把数据写入磁盘，假如不开启，大概会在断电时导致一段时间内的数据丢失。由于redis本身同步数据文件是按上面save条件来同步的，以是有的数据会在一段时间内只存在于内存中。默以为no,appendonlyno
指定更新日记文件名，默以为appendonly.aof,appendfilenameappendonly.aof
指定更新日记条件，共有3个可选值：
no：表现等操纵体系举行数据缓存同步到磁盘（快）
always：表现每次更新操纵后手动调用fsync()将数据写到磁盘（慢，安全）
everysec：表现每秒同步一次（折衷，默认值）appendfsynceverysec
指定是否启用假造内存机制，默认值为no，简单的先容一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘主动换出到内存中vm-enabledno
假造内存文件路径，默认值为/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-memory0
Redisswap文件分成了很多的page，一个对象可以生存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的数据巨细来设定的，作者发起假如存储很多小对象，page巨细最好设置为32大概64bytes；假如存储很大大对象，则可以利用更大的page，假如不确定，就利用默认值vm-page-size32
设置swap文件中的page数量，由于页表（一种表现页面空闲或利用的bitmap）是在放在内存中的，在磁盘上每8个pages将斲丧1byte的内存。vm-pages134217728
设置访问swap文件的线程数,最好不要高出呆板的核数,假如设置为0,那么全部对swap文件的操纵都是串行的，大概会造成比力长时间的耽误。默认值为4,vm-max-threads4
设置在向客户端应答时，是否把较小的包归并为一个包发送，默以为开启glueoutputbufyes
指定在高出肯定的数量大概最大的元素高出某一临界值时，采取一种特别的哈希算法,hash-max-zipmap-entries64,hash-max-zipmap-value512
指定是否激活重置哈希，默以为开启（背面在先容Redis的哈希算法时具体先容）activerehashingyes
指定包罗别的的设置文件，可以在同一主机上多个Redis实例之间利用同一份设置文件，而同时各个实例又拥有本身的特定设置文件include/path/to/local.conf
数据布局
Redis中的value支持五种数据范例:strings,lists,sets,sortedsets,hashes。关于key的计划，有几点必要留意：
key不要太长，只管不要高出1024字节，这不但斲丧内存，而且会低落查找的服从；
key也不要太短，太短的话，key的可读性会低落；
在一个项目中，key最好利用同一的定名模式，比方user:10000:passwd
别的本文只是一个根本的指南，不会涵盖太多的下令，具体请参考Redis的官方文档。
Strings
有人说，假如只利用redis中的字符串范例，且不利用redis的长期化功能，那么，redis就和memcache非常非常的像了。我们可以做一些根本的实行：
在碰到数值操纵的时间，redis会将字符串范例转换成数值，但是假如不是数值会怎么样呢？我们来试试看：
Redis中的数值操纵指令有一个很好的特性是原子性，很多网站都利用redis的这个特性来做技能统计
Lists
Redis中的list的底层实现不是数组而是链表，这就使得在头尾插入新元素的复杂度是常数级别的，但定位元素的时间假如list的巨细比力大的话就会很耗时。lists的常用操纵包罗LPUSH、RPUSH、LRANGE等。我们可以用LPUSH在lists的左侧插入一个新元素，用RPUSH在lists的右侧插入一个新元素，用LRANGE下令从lists中指定一个范围来提取元素。简单来试一下：
lists的应用相称广泛，任意举几个例子：
我们可以利用lists来实现一个消息队列，而且可以确保先后次序，不必像MySQL那样还必要通过ORDERBY来举行排序
利用LRANGE还可以很方便的实现分页的功能
在博客体系中，每片博文的批评也可以存入一个单独的list中
Sets
Redis中的聚集是无序聚集，根本的操纵对应于聚集的操纵，比方说添加、删除、交并差集等等，比方：
聚集的常见应用场景也很多，比方说文章的标签；群聊中的成员等等。
SortedSets
顾名思义，就是把无序的聚集弄有序了，每个元素会关联一个分数score，也就是排序的依据。由于关于有序聚集的相干操纵都是以z开头的，以是通常我们把有序聚集称为zsets。还是来看看具体的例子：
Hashes
哈希是Redis2.0之后才增长支持的数据布局，简单来说就是一个字典，直接看具体例子就很好懂了：
Redis2.8.9版本中添加了这个新的布局，定名也很风趣，走ABB的套路，比如范冰冰高圆圆李思思就是这么个意思。这个布局是用来做基数统计的，基数统计是什么，来看两个例子：1)数据集{1,3,5,7,5,7,8}，那么这个数据集的基数集为{1,3,5,7,8},基数(不重复元素)为5。2)一个网站有很多访客记录，由于每个人不肯定只访问一次，假如我想知道独立访客的人数的话，就必要盘算一个基数，这时间就可以用HyperLogLog。长处在于纵然数据量非常大，盘算所需的空间是小而固定的。每个HyperLogLog的键只占用12KB的内存，但是可以盘算264264个差别的基数。具体怎么实现的我还没有看源码，但估计跟bloomfilter的思绪是一样的。简单举个例子：
由于内部计划的算法，会只管克制出现碰撞，以是在例子中大概不会出现统计禁绝的环境，不外在数据量变大之后，统计数值就不再是正确值。
长期化
固然是内存数据库，一样平常来说为了保险起见，还是会有一些长期化的机制，Redis采取了此中两种方式，一是RDB(RedisDataBase)，也就是存数据，另一种是AOF(AppendOnlyFile)，也就是存操纵。固然，纵然是Redis本身提供的，我们也可以选择用还是不消，假如两种都不消的化，Redis就和memcache差不多了。
具体的下令也很简单，直接SAVE即可，会在安装目次中创建dump.rdb文件。规复数据时，只必要将备份文件移动到redis安装目次并启动redis即可，具体目次在那边可以通过CONFIGGETdir来查察，比方说在我的呆板上：
127.0.0.1:6379CONFIGGETdir
1)"dir"
2)"/usr/local/var/db/redis"
假如用BGSAVE的话，就是在背景举行备份，不会壅闭进程。
RDB
本段内容来自Linux大棚版redis入门教程（https://roclinux.cn/?p=3196）
RDB方式，是将redis某一时候的数据长期化到磁盘中，是一种快照式的长期化方法。
Redis在举行数据长期化的过程中，会先将数据写入到一个临时文件中，待长期化过程都竣事了，才会用这个临时文件更换前次长期化好的文件。正是这种特性，让我们可以随时来举行备份，由于快照文件总是完备可用的。
对于RDB方式，redis会单独创建（fork）一个子进程来举行长期化，而主进程是不会举行任何IO操纵的，如许就确保了redis极高的性能。
假如必要举行大规模数据的规复，且对于数据规复的完备性不黑白常敏感，那RDB方式要比AOF方式更加的高效。
固然RDB有不少长处，但它的缺点也是不容忽视的。假如你对数据的完备性非常敏感，那么RDB方式就不太得当你，由于纵然你每5分钟都长期化一次，当redis故障时，仍旧会有近5分钟的数据丢失。以是，redis还提供了另一种长期化方式，那就是AOF。
AOF
本段内容来自Linux大棚版redis入门教程（https://roclinux.cn/?p=3196）
AOF，英文是AppendOnlyFile，即只答应追加不答应改写的文件。如前面先容的，AOF方式是将实行过的写指令记录下来，在数据规复时按照从前到后的次序再将指令都实行一遍，就这么简单。
我们通过设置redis.conf中的appendonlyyes就可以打开AOF功能。假如有写操纵（如SET等），redis就会被追加到AOF文件的末端。
默认的AOF长期化战略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中），由于在这种环境下，redis仍旧可以保持很好的处理惩罚性能，纵然redis故障，也只会丢失近来1秒钟的数据。
假如在追加日记时，恰好碰到磁盘空间满、inode满或断电等环境导致日记写入不完备，也没有关系，redis提供了redis-check-aof工具，可以用来举行日记修复。
由于采取了追加方式，假如不做任那边理惩罚的话，AOF文件会变得越来越大，为此，redis提供了AOF文件重写（rewrite）机制，即当AOF文件的巨细高出所设定的阈值时，redis就会启动AOF文件的内容压缩，只保存可以规复数据的最小指令集。举个例子大概更形象，假如我们调用了100次INCR指令，在AOF文件中就要存储100条指令，但这显着是很低效的，完全可以把这100条指令归并成一条SET指令，这就是重写机制的原理。
在举行AOF重写时，仍旧是采取先写临时文件，全部完成后再更换的流程，以是断电、磁盘满等题目都不会影响AOF文件的可用性，这点各人可以放心。
AOF方式的另一个长处，我们通过一个“场景再现”来阐明。某同砚在操纵redis时，不警惕实行了FLUSHALL，导致redis内存中的数据全部被清空了，这是很悲剧的事变。不外这也不是天下末日，只要redis设置了AOF长期化方式，且AOF文件还没有被重写（rewrite），我们就可以用最快的速率停息redis并编辑AOF文件，将末了一行的FLUSHALL下令删除，然后重启redis，就可以规复redis的全部数据到FLUSHALL之前的状态了。是不是很神奇，这就是AOF长期化方式的长处之一。但是假如AOF文件已经被重写了，那就无法通过这种方法来规复数据了。
固然长处多多，但AOF方式也同样存在缺陷，比如在同样数据规模的环境下，AOF文件要比RDB文件的体积大。而且，AOF方式的规复速率也要慢于RDB方式。
假如你直接实行BGREWRITEAOF下令，那么redis会天生一个全新的AOF文件，此中便包罗了可以规复现有数据的最少的下令集。
假如运气比力差，AOF文件出现了被写坏的环境，也不必太过担心，redis并不会贸然加载这个有题目的AOF文件，而是报错退出。这时可以通过以下步调来修复堕落的文件：
备份被写坏的AOF文件
运行redis-check-aof–fix举行修复
用diff-u来看下两个文件的差别，确认题目点
重启redis，加载修复后的AOF文件
AOF重写的内部运行原理，我们有须要相识一下。在重写即将开始之际，redis会创建（fork）一个“重写子进程”，这个子进程会起首读取现有的AOF文件，并将其包罗的指令举行分析压缩并写入到一个临时文件中。
与此同时，主工作进程会将新吸取到的写指令一边累积到内存缓冲区中，一边继承写入到原有的AOF文件中，如许做是包管原有的AOF文件的可用性，克制在重写过程中出现不测。
当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。
当追加竣事后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中了。
我们应该选择RDB还是AOF，官方的发起是两个同时利用。如许可以提供更可靠的长期化方案。
加强功能
主从同步
本段内容大部分来自Linux大棚版redis入门教程
像MySQL一样，redis是支持主从同步的，而且也支持一主多从以及多级从布局。主从布局，一是为了纯粹的冗余备份，二是为了提拔读性能，比如很斲丧性能的SORT就可以由从服务器来负担。在具体的实践中，大概还必要思量到具体的法律法规缘故起因，单纯的主从布局没有办法应对多机房跨国大概带来的数据存储题目，这里必要特别留意一下
redis的主从同步是异步举行的，这意味着主从同步不会影响主逻辑，也不会低落redis的处理惩罚性能。主从架构中，可以思量关闭主服务器的数据长期化功能，只让从服务器举行长期化，如许可以进步主服务器的处理惩罚性能。
在主从架构中，从服务器通常被设置为只读模式，如许可以克制从服务器的数据被误修改。但是从服务器仍旧可以担当CONFIG等指令，以是还是不应该将从服务器直接袒露到不安全的网络环境中。假如必须云云，那可以思量给紧张指令举行重定名，来克制下令被外人误实行。
具体的同步原理也值得相识一下：
从服务器会向主服务器发出SYNC指令，当主服务器接到此下令后，就会调用BGSAVE指令来创建一个子进程专门举行数据长期化工作，也就是将主服务器的数据写入RDB文件中。在数据长期化期间，主服务器将实行的写指令都缓存在内存中。
在BGSAVE指令实行完成后，主服务器会将长期化好的RDB文件发送给从服务器，从服务器接到此文件后会将其存储到磁盘上，然后再将其读取到内存中。这个动作完成后，主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器。
别的，要说的一点是，纵然有多个从服务器同时发来SYNC指令，主服务器也只会实行一次BGSAVE，然后把长期化好的RDB文件发给多个卑鄙。在redis2.8版本之前，假如从服务器与主服务器因某些缘故起因断开毗连的话，都会举行一次主从之间的全量的数据同步；而在2.8版本之后，redis支持了服从更高的增量同步战略，这大大低落了毗连断开的规复本钱。
主服务器会在内存中维护一个缓冲区，缓冲区中存储着将要发给从服务器的内容。从服务器在与主服务器出现网络瞬断之后，从服务器会实行再次与主服务器毗连，一旦毗连乐成，从服务器就会把“盼望同步的主服务器ID”和“盼望哀求的数据的偏移位置（replicationoffset）”发送出去。主服务器吸取到如许的同步哀求后，起首会验证主服务器ID是否和本身的ID匹配，其次会查抄“哀求的偏移位置”是否存在于本身的缓冲区中，假如两者都满意的话，主服务器就会向从服务器发送增量内容。
事件处理惩罚
本段内容大部分来自Linux大棚版redis入门教程
数据库原理中很紧张的一个概念是『事件』，简单来说就是把一系列动作看做一个团体，假如此中一个出了题目，应该把状态规复到实行该团体之前的状态。在Redis中，MULTI、EXEC、DISCARD、WATCH这四个指令是事件处理惩罚的底子。
MULTI用来组装一个事件；
EXEC用来实行一个事件；
DISCARD用来取消一个事件；
WATCH用来监督一些key，一旦这些key在事件实行之前被改变，则取消事件的实行。
举个例子：
在上面的例子中，我们看到了QUEUED的字样，这表现我们在用MULTI组装事件时，每一个下令都会进入到内存队列中缓存起来，假如出现QUEUED则表现我们这个下令乐成插入了缓存队列，在将来实行EXEC时，这些被QUEUED的下令都会被组装成一个事件来实行。
对于事件的实行来说，假如redis开启了AOF长期化的话，那么一旦事件被乐成实行，事件中的下令就会通过write下令一次性写到磁盘中去，假如在向磁盘中写的过程中恰好出现断电、硬件故障等题目，那么就大概出现只有部分下令举行了AOF长期化，这时AOF文件就会出现不完备的环境，这时，我们可以利用redis-check-aof工具来修复这一题目，这个工具会将AOF文件中不完备的信息移除，确保AOF文件完备可用。
然后我们来说说WATCH这个指令，它可以帮我们实现雷同于“乐观锁”的结果，即CAS（checkandset）。WATCH本身的作用是“监督key是否被改动过”，而且支持同时监督多个key，只要还没真正触发事件，WATCH都会尽职尽责的监督，一旦发现某个key被修改了，在实行EXEC时就会返回nil，表现事件无法触发。比方：
由于name在exec之前被改变了，可以以为这个值是脏(dirty)的，于是之后的操纵很大概是伤害且没故意义的，天然就不会实行了。
发布订阅
Redis的发布/订阅(pub/sub)是一种消息通讯模子，Redis客户端可以订阅恣意数量的频道，一旦某频道吸取到消息时，订阅它的客户端便会收到消息。这里我们必要两个终端来完成这次实行，在终端1中做如下操纵：
127.0.0.1:6379SUBSCRIBEwdxtubBlog
Readingmessages...(pressCtrl-Ctoquit)
1)"subscribe"
2)"wdxtubBlog"
3)(integer)1
然后在终端2中向该频道发送消息
127.0.0.1:6379PUBLISHwdxtubBlog"newpostupdated!"
(integer)1
127.0.0.1:6379PUBLISHwdxtubBlog"visitwdxtub.comformore!"
(integer)1
然后我们在终端1中就可以看到对应的消息：
127.0.0.1:6379SUBSCRIBEwdxtubBlog
Readingmessages...(pressCtrl-Ctoquit)
1)"subscribe"
2)"wdxtubBlog"
3)(integer)1
1)"message"
2)"wdxtubBlog"
3)"newpostupdated!"
1)"message"
2)"wdxtubBlog"
3)"visitwdxtub.comformore!"
性能测试
在设置好Redis后，我们可以通过自带的性能测试来查察Redis在这台服务器上的表现，据此决定是否应该举行设置和服务调解，比方：
测试内容还是不少的，可以根据这些数据来举行优化相干工作。
毗连与管道
Redis通过监听一个TCP端口大概Unixsocket的方式来吸取来自客户端的毗连，当一个毗连创建后，Redis内部会举行以下一些操纵：
客户端socket会被设置为非壅闭模式，由于Redis在网络变乱处理惩罚上采取的黑白壅闭多路复用模子。
为这个socket设置TCP_NODELAY属性，禁用Nagle算法。Nagle算法实际就是当必要发送的数据攒到肯定程度时才真正举行发包，通过这种方式来镌汰header数据占比的题目。不外在高互动的环境下是不须要的，一样平常来说，在客户端/服务器模子中会禁用。更多信息可在参考链接中查察。
创建一个可读的文件变乱用于监听这个客户端socket的数据发送
Redis管道技能可以在服务端未相应时，客户端可以继承向服务端发送哀求，并终极一次性读取全部服务端的相应。管道技能最明显的上风是进步了redis服务的性能。
分区
本段内容重要来自Redis分区(https://www.runoob.com/redis/redis-partitioning.html)
分区是分割数据到多个Redis实例的处理惩罚过程，因此每个实例只生存key的一个子集。分区的上风有很多，尤其是在大数据当道的本日，更必要利用公道的分区机制来完成更加复杂的工作。
通过利用多台盘算机内存的和值，答应我们构造更大的数据库
通过多核和多台盘算机，答应我们扩展盘算本领
通过多台盘算机和网络适配器，答应我们扩展网络带宽
分区实际上把数据举行了隔离，假如本来应该在同一分区的数据被放在了差别分区，大概本来没有太多关系的数据由于新的业务产生了关系，就会碰到一些题目：
涉及多个key的操纵通常是不被支持的。举例来说，当两个set映射到差别的redis实例上时，你就不能对这两个set实行交集操纵
涉及多个key的redis事件不能利用
当利用分区时，数据处理惩罚较为复杂，比如你必要处理惩罚多个rdb/aof文件，而且从多个实例和主机备份长期化文件
增长或删除容量也比力复杂。redis集群大多数支持在运行时增长、删除节点的透明数据均衡的本领，但是雷同于客户端分区、署理等其他体系则不支持这项特性。然而，一种叫做presharding的技能对此是有资助的。
Redis有两种范例分区。假设有4个Redis实例R0，R1，R2，R3，和雷同user:1，user:2如许的表现用户的多个key，对既定的key有多种差别方式来选择这个key存放在哪个实例中。也就是说，有差别的体系来映射某个key到某个Redis服务。
范围分区
最简单的分区方式是按范围分区，就是映射肯定范围的对象到特定的Redis实例。比如，ID从0到10000的用户会生存到实例R0，ID从10001到20000的用户会生存到R1，以此类推。这种方式的不敷之处是要有一个区间范围到实例的映射表，同时还必要各种对象的映射表，通常对Redis来说并非是好的方法。
哈希分区
别的一种分区方法是hash分区。这对任何key都实用，也无需是object_name:这种情势，只必要确定同一的哈希函数，然后通过取模确定应该生存在哪个分区即可。
总结
相比于在学校必须手写本身的缓存，利用Redis（或是memcache）简直太爽了，工作一段时间了，越发以为技能的门槛着实越来越低，怎样打造高效团队，怎样把架构计划得更加公道，才是真正表现差距的地方。
版权阐明：内容泉源网络，版权归原创者全部。除非无法确认，我们都会标明作者及出处，如有侵权烦请告知，我们会立即删除并表现歉意。谢谢。
-END-
架构文摘
ID：ArchDigest
互联网应用架构丨架构技能丨大型网站丨大数据丨呆板学习
更多出色文章，请点击下方：阅读原文
CopyrightYourWebSite.SomeRightsReserved.
京ICP备2023016396号-1PoweredByESCLINK.
我要评论