Redis数据结构以及应用场景

1. Redis数据结构以及应用场景

1.1. Memcache VS Redis

1.1.1. 选Memcache理由

1. 系统业务以KV的缓存为主，数据量、并发业务量大，memcache较为合适
2. memcache将所有数据存储在物理内存中。Redis则有自己的VM机制，当数据超量时，会引发swap，影响计算机服务器性能
3. memchache使用多线程的模式（主线程监听，work子线程工作），而Redis使用单线程，难以充分利用目前的多核CPU，我要求的是快快快，压榨光每一个资源的性能

1.1.2. 选Redis的理由

1. 虽然Redis在数据的持久化方面并不那么完美，但是可以在系统奔溃发生意外时，提供一层保障
2. Redis天然高可用，官方提供了sentinel集群管理工具，释放了我们大量的工作内容
3. Redis能存储内容较Memcache的1M要大多了
4. Redis代码质量比Memcache好多了
5. 系统不仅仅只用到KV，我们需要用到Redis丰富的数据结构以及相关功能函数，Memcache不适合我的系统

1.2. Redis数据结构

1.2.1. String

1.2.1.1. 概念

1. key value都是String的map

1.2.1.2. 分布式锁

//设置锁字符串键，若存在则设置失败
SETNX("couponcode","lock") == 1 //成功获取锁

SETNX(lockKey,'lock')==0//有人占用资源获取锁失败

业务处理完毕释放分布式锁
DEL(lockKey);

//设置锁字符串键的失效时间，防止宕机，系统运行意外，导致无法释放锁
PEXPIRE(lockKey, lockMilliSeconds)

1.2.1.3. 字符串键-计数器

通过字符串这两个API即可实现：
INCR key  //INCR readcount::{帖子ID}    每阅读一次
GET key     //GET readcount::{帖子ID}    获取阅读量

实战情况通常取部分数据到内存再进行分配

1.2.2. Hash键

1.2.2.1. 概念

类似HashMap<String,HashMap<String,String>> h = new HashMap<>();

1.2.2.2. hash键存在的意义何在？

1. Hash键可以将信息凝聚在一起，而不是直接分散存储在整个Redis中，这不仅方便了数据管理，还可以尽量避免一定的误操作
2. 避免键名冲突
3. 减少内存占用

未完待续。。。