redis学与思系列（2）

上篇文章简单的介绍了 redis 的使用场景和优缺点，本文接着解答以下几个问题：

• Redis有哪些数据结构？
• 使用过Redis分布式锁么，它是什么回事？
• Redis 的数据类型，以及每种数据类型的使用场景?
• 使用过Redis做异步队列么，你是怎么用的？

这些问题实际上归结起来都和redis 提供的数据结构有关，接下来重点带着这些问题重点解读redis的数据结构和使用场景。（· 我觉得技术本身不能创造价值，只有找到对应的适用场景，解决业务中的问题，才能产生价值 ）。

 redis 是基于key-value的数据库，所有的key都是字符串类型，针对value值的不同，又划分为字符串，列表，集合，有序集合，散列表，（位图，hyperLoglog，GEO） 等等`。
复制代码

本文主要介绍 字符串 有代表性的一些命令以及对应的适用场景。

命令: SET key value [EX seconds] [PX milliseconds] [NX|XX] :

将字符串值 value 关联到 key,如果 key 已经持有其他值， SET 就覆写旧值，无视类型,对于某个原本带有生存时（TTL）的键来说， 当 SET 命令成功在这个键上执行时， 这个键原有的 TTL 将被清除.
  
  参数介绍:
  EX second ：设置键的过期时间为 second 秒。 
  PX millisecond ：设置键的过期时间为 millisecond 毫秒
  NX ：只在键不存在时，才对键进行设置操作。 
  XX ：只在键已经存在时，才对键进行设置操作。
复制代码

常见使用场景：

• 缓存：可以将要缓存的数据序列化成json串，存储在key对应的value里，同时可以为其指定过期时间;

• 分布式锁： 分布式锁设计时要考虑以下问题：

  互斥性
     可重入性
     死锁
     锁的性能
  复制代码

采用redis实现分布式锁，网上很多同学都给了实现方案，此处就不啰嗦了。redis 实现分布式锁的优点是加锁释放锁很快。不过采用redis 实现分布式锁是有一些缺陷的，比如因为依赖键的过期机制，会导致如果加锁时正常的业务代码执行时间超出了键的过期时间，业务代码还没有执行完时，锁已经释放掉了，这样其他线程就有可能获取锁，进而导致多个线程同时获得锁，不能严格意义上保证锁的排他性。所以在业务选择时要考虑到这些方面。

命令： INCR key

将 key 中储存的数字值增一。

如果 key 不存在，那么 key 的值会先被初始化为 0 ，然后再执行 INCR 操作。

如果值包含错误的类型，或字符串类型的值不能表示为数字，那么返回一个错误`
复制代码

常见使用场景:

• 计数器: 比如用来统计页面的uv(用户访问量)
• 简单的限速器：结合计数功能+过期机制，统计单位时间的访问量来实现限流。

命令: SETBIT key offset value

对 key 所储存的字符串值，设置或清除指定偏移量上的位(bit)。

 位的设置或清除取决于 value 参数，可以是 0 也可以是 1 。

 当 key 不存在时，自动生成一个新的字符串值。

 字符串会进行伸展(grown)以确保它可以将 value 保存在指定的偏移量上。当字符串值进行伸展时，空白位置以 0 填充。

 offset 参数必须大于或等于 0 ，小于 2^32 (bit 映射被限制在 512 MB 之内)。
复制代码

适用场景:

统计和查找： 结合bitcount指令，比如从10亿个无序的整数（范围在0-40亿）统计出前10个数，这种场景下使用bitmap 存储时会极大的缩小占用内存空间.

总结

本文仅仅是简单的介绍了一下redis 字符串类型的部分操作命令以及其相应的使用场景，关于redis的其他数据类型以及相应的使用场景，再后续的文章中进一步进行介绍。