内存数据库实战

内存数据库特点

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的风险

3. 大 List. Set. Hash，field 数量巨大。无法横向扩容，迁移. 升级 server 会造成阻塞，获得大量元素时延迟较大阻塞其他命令。建议切割成多个小的 list. set. hash。


4. 大 String，value 大于 20K。当 ops 为 10000，流量即为 200M,容易打满单个 server 的带宽配额. 阻塞其他命令执行。一般业务很难有效的控制value较大时key的访问频率，建议value 尽量较小。


5. keys 命令会阻塞其他命令。建议用分时机制的 scan 命令代替。


6. 局部读写，一段时间仅访问少量的几个分片，客户端会不停的新建. 销毁连接。建议调整 连接池配置. 增大最大空闲连接数. 空闲连接存活时长。


7. 一次业务调用需要访问多次 JIMDB 服务端，导致 OPS 成倍增长，应尽量避免。