Redis的各项功能解决了哪些问题？

上面这一大段解释了这么多，不知有没有发现不管是第一个路子还是第二个路子，都有一个共同的东西存在，那就是分布式服务中所有服务器以及其能提供的服务的信息。这些信息无论如何也是要存在的，区别在于第一个路子是把这部分信息单独来管理，用这些信息来协调后端的多个独立的redis服务器;第二个路子则是让每一个redis服务器都持有这份信息，彼此知道对方的存在，来达成和第一个路子一样的目的，优点是不再需要一个额外的组件来处理这部分事情。

Redis Cluster的具体实现细节则是采用了Hash槽的概念，即预先分配出来16384个槽：在客户端通过对Key进行CRC16(key)% 16384运算得到对应的槽是哪一个;在redis服务端则是每个服务器负责一部分槽，当有新的服务器加入或者移除的时候，再来迁移这些槽以及其对应的数据，同时每个服务器都持有完整的槽和其对应的服务器的信息，这就使得服务器端可以进行对客户端的请求进行重定向处理。

4 客户端的Redis

上面的第三小节主要介绍的是Redis服务端的演进步骤，解释了Redis如何从一个单机的服务，进化为一个高可用的、去中心化的、分布式的存储系统。这一小节则是关注下客户端可以消费的redis服务。

4.1 数据类型

redis支持丰富的数据类型，从最基础的string到复杂的常用到的数据结构都有支持：

1. string：最基本的数据类型，二进制安全的字符串，最大512M。

2. list：按照添加顺序保持顺序的字符串列表。

3. set：无序的字符串集合，不存在重复的元素。

4. sorted set：已排序的字符串集合。

5. hash：key-value对的一种集合。

6. bitmap：更细化的一种操作，以bit为单位。

7. hyperloglog：基于概率的数据结构。

这些众多的数据类型，主要是为了支持各种场景的需要，当然每种类型都有不同的时间复杂度。其实这些复杂的数据结构相当于之前我在《解读REST》这个系列博客基于网络应用的架构风格中介绍到的远程数据访问(Remote Data Access = RDA)的具体实现，即通过在服务器上执行一组标准的操作命令，在服务端之间得到想要的缩小后的结果集，从而简化客户端的使用，也可以提高网络性能。比如 如果没有list这种数据结构，你就只能把list存成一个string，客户端拿到完整的list，操作后再完整的提交给redis，会产生很大的浪费。

4.2 事务

上述数据类型中，每一个数据类型都有独立的命令来进行操作，很多情况下我们需要一次执行不止一个命令，而且需要其同时成功或者失败。redis对事务的支持也是源自于这部分需求，即支持一次性按顺序执行多个命令的能力，并保证其原子性。

4.3 Lua脚本

在事务的基础上，如果我们需要在服务端一次性的执行更复杂的操作(包含一些逻辑判断)，则lua就可以排上用场了(比如在获取某一个缓存的时候，同时延长其过期时间)。redis保证lua脚本的原子性，一定的场景下，是可以代替redis提供的事务相关的命令的。相当于基于网络应用的架构风格中介绍到的远程求值(Remote Evluation = REV)的具体实现。

4.4 管道

因为redis的客户端和服务器的连接时基于TCP的， 默认每次连接都时只能执行一个命令。管道则是允许利用一次连接来处理多条命令，从而可以节省一些tcp连接的开销。管道和事务的差异在于管道是为了节省通信的开销，但是并不会保证原子性。

4.5 分布式锁

官方推荐采用Redlock算法，即使用string类型，加锁的时候给的一个具体的key，然后设置一个随机的值;取消锁的时候用使用lua脚本来先执行获取比较，然后再删除key。具体的命令如下：

SET resource_name my_random_value NX PX 30000if redis.call("get",KEYS[1]) == ARGV[1] then return redis.call("del",KEYS[1])else return 0end  
总结  

本篇着重从抽象层面来解释下redis的各项功能以及其存在的目的，而没有关心其具体的细节是什么。从而可以聚焦于其解决的问题，依据抽象层面的概念可以使得我们在特定的场景下选择更合适的方案，而非局限于其技术细节。

以上均是笔者个人的一些理解，如果不当之处，欢迎指正。　

（编辑：辽源站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!