内存数据库实战

本是古典何须时尚 2022-05-23 12:13 207阅读 0赞

**内存数据库特点**

**SERVER为单线程处理模式**，在处理用户请求的过程中，还会定期插入定时任务，比如:

1）过期KEY的删除  
2）链接超时检查  
3）AOF文件重写  
4）扩容存放数据的dic容量

这些定期任务大概100ms会触发一次。当有大量的KEY同时过期时，删除过期KEY的任务可能会执行约20ms后才会退出。 大KEY(线上看到过list 的elements超过百万的)删除时会阻塞比较长的时间，具体时间见测试结果

**大KEY的危害**：  
1）OPS低也会导致流量大，比如一次取走100K的数据，当OPS为1000时，就会产生100M/s的流量  
2）如果为list,hash等数据结构，大量的elements需要多次遍历，多次系统调用拷贝数据消耗时间  
3）主动删除、被动过期删除、数据迁移等，由于处理这一个KEY时间长，而发生阻塞  
  
**热KEY的危害**：  
1）请求过于集中，导致单个shard压力过大，不能发挥集群多分片的优势  
2）当单个shard无法满足性能时，不能通过扩容解决

## **读从须知** ##

正常情况下，主从处于增量同步状态下，延迟在ms级别，

异常情况下，当写流量大，链接断开时间长，从追不上主的增量部分，就会发生全量同步，在全量同步期间，和SLAVE拿到全量数据加载数据到内存，主从的数据可能差异比较大，甚至没有数据，这个时间长度在秒级到分钟级别不等。

当业务读从时，需要知道，当数据延迟或者没有时不会发生灾难性的后果，当然也不能因为有延迟就拒绝使用，还是要看场景，权衡好读压力和延迟哪个代价更大，JIMDB团队也会尽量保证主从数据延迟小。

## **最佳实践** ##

1. 单个 key 热读导致延迟变高。

1）增加多副本，分担读流量

2）不要求强一致的用户，启用客户端本地缓存

3）对于秒杀等流量突增场景，调整链接池，保持少量空闲链接

2. 单个 key 热写导致延迟变高

1）应避免该情况发生

2）对数据可靠性要求不高场景，建议去掉从副本，降低由于写的过快增量同步跟不上，触发全量同步，进而阻塞master的风险