主从架构(读写分离)潜在风险

主从架构、读写分离示意图

 

1、读到过期数据

Redis性能高主要得益于纯内存操作，但内存存储介质的成本过高，所以数据的存储有一定的约束。

通常会设置过期时间，对于一些使用不是很频繁的数据，会定期删除，提高资源的利用率。

删除过期数据

1、惰性删除。

即被动删除，当数据过期后，并不会马上删除。而是等到有请求访问时，对数据检查，如果数据过期，则删除数据。

优点：不需要单独启动额外的扫描线程，减少了CPU资源的损耗。

缺点：大量的过期数据滞留内存中，需要主动触发、检查、删除，否则会一直占用内存资源。

2、定期删除。

每隔一段时间，默认100ms，Redis会随机挑选一定数量的Key，检查是否过期，并将过期的数据删除。

当客户端往主库写入数据后，并设置了过期时间，通常数据会以异步方式同步给从库。

1、如果此时读主库，数据已经过期，主库的惰性删除会发挥作用，主动触发删除操作，客户端不会拿到已过期数据

2、但是如果读从库，则有可能拿到过期数据

一般采用 EXPIRE 和 PEXPIRE，表示从执行命令那个时刻开始，往后延长 ttl 时间。严重依赖于 开始时间 从什么时候算起。

• EXPIRE：单位为秒

• PEXPIRE：单位为毫秒

• t1 时刻，主库写入一个带过期时间的数据， t3之前有效

• 由于网络原因、或者缓存服务器的执行效率，从库的命令并没有立即执行。一直等到了 t2 才开始执行， 数据的有效期则会延后到 t5

• 如果，此时客户端访问从库，发现数据依然处于有效期内，可以正常使用（读到过期数据）

主从时间节点同步，保持一致！使用EXPIREAT 和 PEXPIREAT，相对简单，在某一时间点过期，可以避免上述问题。

• EXPIREAT：单位为秒

• PEXPIREAT：单位为毫秒

 数据不一致（从库同步落后）

主要有两个：

1、服务器间的网络传输延迟

2、从库已经收到主库的命令，由于是单线程执行，前面正在处理一些耗时的命令（如：pipeline批处理），无法及时同步执行。

解决方案：

1、主从服务器尽量部署在同一个机房，并保持服务器间的网络良好通畅

2、监控主从库间的同步进度，通过info replication命令 ，查看主库接收写命令的进度信息（master_repl_offset），从库的复制写命令的进度信息（slave_repl_offset）

当然，其他中间件或者服务的主从架构都会有此类问题！