Redis开创了一种新的数据存储思路，使用Redis，我们不用在面对功能单调的数据库时，把精力放在如何把大象放进冰箱这样的问题上，而是利用Redis灵活多变的数据结构和数据操作，为不同的大象构建不同的冰箱。

Redis常用数据类型

Redis最为常用的数据类型：

1.String   

2.Hash   

3.List  

4.Set   

5.Sorted set  

1、String

常用命令:  set,get,decr,incr,mget 等。

应用场景：String类型是最简单也是最常用的redis数据结构，key/value格式完全可以取代Memcached作为缓存服务器，单机的测试效果显示redis的效果更好。

set、get：最简单的数据缓存

mset、mget： 批量操作，把数据统一传回客户端，节省网络io时间

decr、incr：计数器

append命令：可以作为时间序列，配合getrange、setrange，对字符串进行操作，目前redis还木有修剪操作

setbit、getbit： 省内存的好命令，可以作为简单的布尔过滤器来判断用户是否执行过某些操作

2、List

常用命令：lpush,rpush,lpop,rpop,lrange等。

应用场景：List的应用场景很多，应用也相当广泛

lpush、lpop：天然的队列操作，轻松实现队列任务，Celery的存储容器我们选的就是redis

lpush、ltrim： 显示最新的数据，很好用的！比如：游戏上方的跑马灯，就可以用这两个命令来存储最新的50条记录

还有一些其他操作：堵塞式的blpop， lrange（O(n)）， lindex（O(n)），linsert（O(n)）， llen（O(1)），lrem(O(n))，lset(O(n))

3、Hash

常用命令：hget,hset,hgetall 等。

应用场景：以前在memcached中如果保存一个大的数据，经常用序列化之后保存，取出来反序列化后使用，即不经济实惠，在高并发下还存在原子性问题，在redis中， 用哈希实现，so easy啦！

hget、hset： 实现一个key对应一个数据集集合，数据集集合里包含多个单独的key/value键值对，操作依然是原子性的

hmget、hmset、hgetall： 批量操作，节省网络io时间哦

hincrby: 对哈希里域值，进行原子性的加1

其他操作： hdel（O(n)）、 hkeys（O(n)）、hexits（O(1)）、hvals（O(n)）、hscan（O(n)）

4、Set

常用命令：

sadd,spop,smembers,sunion 等。

应用场景：set与list类似，只是set是经过去重的集合，需要一个不重复的数据结构，就要考虑考虑set

sadd： 存储一个不重复数据的数据集合

sunion、sdiff、sinter： 进行集合处理，例如微博中，将一个用户关注的所有人放入set集合中，通过并集、交集、差集操作，实现`共同关注`、`共同喜好`、`二度好友`等功能

其他操作：srem、spop、scard、sismember、smove、srandmember

5、Sorted Set

常用命令：

zadd,zrange,zrem,zcard等

应用场景：set是无序的，而Sorted set 顾名思义，它是有序的，由key、member和score组成，需要一个有序而且不重复的数据结构，就要考虑考虑sorted set

zadd：存储一个按照score排序的数据集合，添加时自动排序，例如：优先队列，普通消息的score为1，重要消息的score为2，然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。

zrange、zrangebyscore等等：按照score顺序获取数据集，例如：微博的时间流信息，把发布时间作为score。还可以用来处理过期数据。后台任务使用ZRANGE…SCORES查询排序集合，取出最新的10个项目。如果发现unix时间已经过期，则在数据库中删除条目。

zrank： 排行榜功能，score作为投票结果

其他操作：zcard、zcount、zincrby、zrem、zscore，以及set的集合操作

Redis 的 5 个常见使用场景

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，你可以从这里去查看。

排行榜/计数器

Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（Sorted Set）也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。所以，我们要从排序集合中获取到排名最靠前的10个用户–我们称之为“user_scores”，我们只需要像下面一样执行即可：

当然，这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数，你需要这样执行：

ZRANGE user_scores 0 10 WITHSCORES

Agora Games就是一个很好的例子，用Ruby实现的，它的排行榜就是使用Redis来存储数据的，你可以在这里看到。

Redis实际应用场景

Redis在很多方面与其他数据库解决方案不同：它使用内存提供主存储支持，而仅使用硬盘做持久性的存储；它的数据模型非常独特，用的是单线程。另一个大区别在于，你可以在开发环境中使用Redis的功能，但却不需要转到Redis。

转向Redis当然也是可取的，许多开发者从一开始就把Redis作为首选数据库；但设想如果你的开发环境已经搭建好，应用已经在上面运行了，那么更换数据库框架显然不那么容易。另外在一些需要大容量数据集的应用，Redis也并不适合，因为它的数据集不会超过系统可用的内存。所以如果你有大数据应用，而且主要是读取访问模式，那么Redis并不是正确的选择。

然而我喜欢Redis的一点就是你可以把它融入到你的系统中来，这就能够解决很多问题，比如那些你现有的数据库处理起来感到缓慢的任务。这些你就可以通过Redis来进行优化，或者为应用创建些新的功能。在本文中，我就想探讨一些怎样将Redis加入到现有的环境中，并利用它的原语命令等功能来解决 传统环境中碰到的一些常见问题。在这些例子中，Redis都不是作为首选数据库。

Redis使用经验

一、Redis部署

本司由于平时的数据量不大，一直使用的三台redis实例，一主两从，三个哨兵sentinel分别监视三个redis实例作为高可用性的保障，这次活动的预估参与人数以及请求并发量很大，所以为了保证高可用性，在部署时做了一下变更方案：

更换SSD硬盘，并增加内存至128G （简单粗暴，效果显著）

双机房两组Redis实例，一组对外服务，另一组作为热备份，不提供服务并定时备份，服务中的实例出现故障，立即切换备份实例为服务实例

OS参数：vm.over_commit_memory配置  默认为0，改为1

Redis的快照、AOF文件重写、主备同步等功 能都依赖于fork系统调用，以快照（bgsave/save）为例，Redis会fork一个子进程出来，由子进程来将当前的数据存储为一个RDB文件。

vm.over_commit_memory会影响到内存分配，其值可以是：

0： 表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程。

1： 表示内核允许分配所有的物理内存，而不管当前的内存状态如何。

2： 表示内核允许分配超过所有物理内存和交换空间总和的内存。

vm.over_commit_memory默认值为0，在该配置下，当Redis执行fork时，服务器可用内存必须大于Redis当前使用内存2倍时，fork才能成功。

而实际上Linux在fork时，使用COW(copy-on-write)技术，子进程共享父进程的地址空间，只有共享地址空间发生改变时，才需要复制改变部分的内存；大部分情况下，fork子进程并不会导致内存使用翻倍，为fork预留一倍的内存是完全没有必要的，Redis启动时也会建议使用者将vm.over_commit_memory设置为1。

OS参数：vm.swapiness设置为0

Redis是全内存的KV数据库，当服务器内存不足时，OS的swap机制可能会把Redis的部分数据换出到磁盘，访问Redis时，如果被访问的数据刚好不在内存里，则会产生缺页中断，从磁盘读取数据，这种行为会极大的影响Redis服务的性能。

为保证Redis服务的性能，应该尽量避免发生swap，将vm.swapiness设置为0（该参数可在0-100之间取值，默认为60，越高使用swap空间的可能性越大）。

OS参数：transparent hugepage

Linux-2.6.38内核引入透明大内存页的支持，这个参数对Redis有利有弊。

好处在于：大内存页意味着更小的页表，fork的开销会降低不少

坏处在于：大内存页，意味着页被修改的几率更大，COW时拷贝成本更高

二、压测过程中遇到的问题及解决方案

保证服务可靠性，对主要单接口压测，以及复合场景下的多接口压测，观察接口的响应时间以及服务的吞吐量，还有对突发情况下的Redis机器故障转移，如机房断电，主redis挂掉等情况。

问题：

业务逻辑复杂，频繁访问redis，接口响应时间有提升空间

线上要清空一个db的数据，执行flushdb后，数据依然存在（原因：该db内数据量大，清空操作超过3秒，sentinel发现3秒内，master无正确响应，就将slave拉起作为master，从进行同步，陷入循环。。。）

Redis目前的主从同步机制，主从连接断开后，如果从落后的数据超过1M（可配置，越大内存开销越大），则需要重新全量同步一次，一次全量同步会产生极大的内存、磁盘、CPU及网络开销。主从全量同步过程中，如果写入比较多，主从同步缓冲区就会不断累积写入的数据，当累积的数据超出限制时，主从连接就会断开，此时从又必须重新向主请求全量同步，如此往复... 导致同步一直不能成功

数据量很大时，redis的bgsave操作，虽然是子进程操作，但是也会阻塞redis，导致超时

　　 方案：

mysql读写分离，并分库，分表

redis数据分片，把重要、不重要的数据分开到两个redis实例分别存放

代码中减少redis网络IO请求，多用mget、hmget、pipeline等一次性读多条数据命令

代码中考虑用更合适的redis数据结构以及时间复杂度少的命令。 Instagram公司优化Redis使用内存案例

设计数据结构时，尽量减小单个key的value大小，如果单例redis中数据量过大，故障恢复或者同步过程会很慢。单例redis最大使用内存一定要小于机器最大内存的一半。

清空一个数据量很大的db前，先调大sentinel的自动故障转移时间，清空后再设置回来。

适当扩大client-output-buffer-limit slave 256mb 64mb 60 的配置值

一定要设置限流，运维层限制一道，代码层限制一道，保证整体服务器不宕机。

　　备选方案：

复杂的redis操作，可以考虑用短小的lua脚本执行，用eval和evalsha命令执行（优点：充分利用CPU，减少网络IO时间。缺点：不方便维护，要保证脚本不阻塞）

传统的一主多从A--B&C 当把B拉起为master时，C仍然会清空自身数据来同步B，psync的断点续传对此无作用，所以考虑改为变为A--B--C同步结构

redis集群（时间紧，考虑但是暂时不会采用）

采用主不开持久化，从开持久化，不会出现数据量大，bgsave导致的连接超时情况（缺点：A--B&C模式下，A故障并自动拉起或者由sentinel把B被拉起为master，中间的心跳检测过程中，还是会有一个间隔，导致从同步主，发现A没有数据，会清空自身的数据，很危险！）