Redis 高性能的原因

Redis 的读写性能达到 10w/s，主要基于以下原因：

  • 数据主要放在内存中。
  • Redis 使用距离 OS “层次更近”的 C 语言实现。
  • Redis 使用单线程架构，没有很高的 lock contention。
  • IO 多路复用技术
  • Redis 的代码实现得优雅而兼顾性能

Redis 的数据结构

Redis 本身是 Remote Dictionary Server 的简称，其中，老的、常见的数据结构有：

  • 字符串
  • 哈希
  • 列表
  • set（集合）
  • zset（有序集合）

但后来追加了几种新颖的数据机构，包括：bitmap、hyperloglog，更后来更添加了 GEO 地理信息相关的工具。

基于这些数据结构，我们可以实现一些常见的功能：

  • 键过期，可以用来实现缓存，进而实现分布式锁。
  • 发布订阅功能，进而实现消息系统（待尝试）。
  • Lua 脚本功能，可以实现自定义的 Redis 命令（待尝试）。
  • 实现简单的事务功能，能在一定程度上实现事务特性。
  • 提供流水线功能，能够让客户端一次性把一批命令一次性上传到 Redis 里，能够合并 IO 并减少网络开销（注意，不同于事务特性）。

redis 有一个很优秀的实现，不需要像 memcache 一样依赖于 libevent 之类的类库（值得研究）。

Redis 应用场景

  1. 缓存

搭配使用自带的缓存（1）超时时间（2）最大内存控制加内存溢出后的淘汰策略（待验证），可以制造一个稳定的缓存集群。

  1. 排行榜（社交网络数据存储）

有序数据集合（sorted set）可以制造各种维度的排行榜。

3.计数器应用（社交网络数据存储）

不要使用 mysql 来制造 counter

4.其他社交网络数据存储

用 8 种数据结构可以比较合理地实现、存储各种社交网络里的踩、赞、粉丝、好友数据。

Redis 自带比较丰富的集合操作。

5、消息队列系统

消息队列可以拿来做业务解耦，非实时削峰。

Redis 有新的 pub/subscribe 和 blocking queue 功能。

Redis 不适合的应用场景

Redis 本身是热存储为主，应该存热数据为主，应该尽量区分热数据和冷数据，把冷数据排出在热数据之外，这样才能合理地提高内存利用效率。
对于食品网站，视频信息是跨业务线的热数据，而每个电视剧的观众信息，则是偏冷的数据。

Redis 本身不支持传统关系型数据库复杂的 CRUD 复杂查询语句。

关于 Redis 我们不知道的事情

不要只把 redis 当做 get、set、del 的黑盒，开发和运维同样重要。