redis学习

分布式高性能缓存Redis，高吞吐消息中间件（多次）。

• redis大纲：

• 缓存指cpu上的一种告诉存储器。现在指的是存储在计算机上的原始数据集（内存）的复制集；缓存是系统快速响应的关键技术之一。以空间换时间。

• DB的缓存减缓DB的压力。redis是内存数据库。

• 使用缓存的优势：1.提升用户体验；2.减轻服务器压力；3.提升系统性能。代价：硬件支出、缓存击穿（高并发）、无法实时数据同步、多个redis客户端并发修改数据冲突；

• 缓存读写模式：读时先读缓存，缓存没有就读数据库，然后取出数据更新缓存，同时返回响应。写模式：先更新数据库，再删除旧的缓存，替换相关的缓存（更新需要遍历耗性能）。

• 缓存表结构是一致的。

• Redis

  • 远程字典服务器：C语言开发的高性能键值对内存数据库。五种数据类型：字符串（key）、散列、列表、集合、有序集合。Nosql的形式存储(k-v)。
  • 应用场景：缓存、DB、seesion分离、队列、排行、签到、分布式锁、冷热数据交换。db-冷数据。
  • Jedis：jedis 对像的api操作：set/get。
  • redis淘汰策略：达到上限则会进行物理内存的交换；设置maxmemory后靠近这个值则会激活缓存淘汰策略，直接从内存中删除数据；不设置则为无限大；某些场景下无需淘汰策略，比如固定的kv，作为数据库使用；
    • 删除策略：定时、惰性（访问时发现失效则删除）、主动删除（）、LRU算法：删除使用访问时间最久远的key；LFU：最不经常使用的，最近使用最少-以后也最少；random、ttl：将要过期的数据key。

    • 在redis 3.0中有6种淘汰策略：

      • noeviction: 不删除策略。当达到最大内存限制时, 如果需要使用更多内存,则直接返回错误信息。（redis默认淘汰策略）
      • allkeys-lru: 在所有key中优先删除最近最少使用(less recently used ,LRU) 的 key。
      • allkeys-random: 在所有key中随机删除一部分 key。
      • volatile-lru: 在设置了超时时间（expire ）的key中优先删除最近最少使用(less recently used ,LRU) 的 key。
      • volatile-random: 在设置了超时时间（expire）的key中随机删除一部分 key。
      • volatile-ttl: 在设置了超时时间（expire ）的key中优先删除剩余时间(time to live,TTL) 短的key。
  • Redis持久化：Redis是内存数据库，宕机后会数据消失；重启后恢复需要持久化机制；RDB&AOF。redis持久化是为了更多的恢复数据而不是存储数据。
  • RDB：通过快照的方式完成这一刻的数据存储，不关注过程。
  • AOF：AOF文件中存储的是redis指令，同步命令到AOF文件的过程分为三个阶段：命令传播、缓存追加、文件写入和保存。
  • RDB和AOF对比：混合持久化：rdb 的头加aof的身体。服务器启动生成伪客户端--执行aof指令--最终还原数据库的状态。
  • Redis发布订阅：publish、subscribe、psubscribe；
  • 哨兵模式：
  • 事务：单个的逻辑单元执行的一系列操作；ACID特性。不支持回滚。
  • lua轻量小巧的脚本语言，用C语言编写并以源代码的形式开放。
    • 监视器：client发的命令给服务器则会同时将指令发送给监视器（监视其他客户端交互）。
    • 利用call（）实现向监视器发送命令，这个函数的作用是将命令打包成协议，发送给监视器。
  • redis慢查询机制：conf。
  • 高可用方案：多机和集群来保证redis的高可用；主机无需配置，从节点可以配置conf；哨兵模式可以主从切换，主宕机从可读不可写。主从同步psync（区分是否第一次同步）。
  • 从服务器每秒一次向主服务器发送请求；
  • Raft协议是用来解决分布式系统一致性问题的协议；raft协议三种状态：Leader/Follwer/Candidate。

• Redis经典问题

• 缓存穿透：高并发下查询key不存在的数据，穿过缓存库直接访问DB，导致DB压力过大而宕机。不存在的key。
• 解决：1.对不存在的key也加入缓存（过期时间小）；2.使用布隆过滤器（对key采用hash存储，hash取模）存在则继续，不存在则打回；
• 雪崩：大量缓存在某个时间段内同时失效，造成db压力过大崩溃；
• 缓存击穿：热点key过期，采用分布式锁控制访问线程，让其他线程处于等待；若不设置超时时间，会造成写一致性问题；
  • 数据不一致：缓存数据不会及时的更新造成脏读，高并发下很容易出现问题。延时双删：先更新数据库同时删除缓存，读的时候再填充缓存（可能读的时候并未写完，最后还是不一致）；2s后再删除一次缓存；设置缓存过期时间；缓存删除失败记录到日志中，利用脚本提取记录再次删除；
• 数据并发竞争：并发访问redis，出现顺序问题；解决：1.分布式锁（setnx）加时间戳（记录先后）；2.消息队列：将set操作放于队列中使其串行化；
• Hot key：几十万访问某个redis key，达到网络上线，导致redis某个服务器宕机；解决：1.预估热key；2.统计热key；3.在proxy端进行；4.redis自带的指令；5.大数据领域流式计算框架实时统计。处理key：1.变分布式为本地缓存；2.集群式每个主节点都备份数据，分流的作用；3.利用热点数据限流熔断机制；
  • big key：value很大；热门话题的讨论、粉丝列表、图片；数据的不均衡性；大key占用内存；性能下降；操作时间过长造成阻塞；cli--bigkey指令、分析rdb文件。
  • 处理：分拆为多个key-v；
  • 分布式锁：乐观锁和悲观锁防止进程同时访问共享资源造成安全隐患。存在问题：单机：高可用无法保证锁成功。
• CAP不可能同时存在：P是多机，ap或cp；redis不保证随时一致性：ap模型；分布式锁是：cp。当业务不需要强一致性的时候就可以使用redis作为分布式锁。
• redison分布式锁：
• redis底层依靠字典实现：对redis的crud操作就是对字典的操作；数据存在数组中，时间效率高；hash算法hash(key)%len(arr)的方式定位存储位置下标；类似于拉链法产生的数组；