缓存
rocksdb 本地缓存 ，无网络访问，磁盘容量大，可以做缓存兜底，服务失败兜底以及大数据量缓存使用
redis 分布式缓存 ，具有极高的读写性能，具有分布式锁等同步方式使用。
需要缓存的数据
发送者信息
接受者信息
消息
消息模板 to 客户端
比如说 私信 ， 发送私信的时候 ，发送者的个人信息 ，接受者的个人信息 在半小时之内可以缓存。必然会有多次用户信息访问，比如接受者是否在线 。 发送方昵称等 。（点赞，关注，回复都是一样的）
历史消息 这块 ，用户通常会下拉查询历史消息 。这块我们虽然分表的方式降低了查询成本 。为什么不把查询数据缓存到缓存中， 后面指定时间内，直接在缓存中查询呢
未读消息，在会话列表接口被调用的时候，是否可以将部分会话的未读消息直接加载到缓存 ，设置半小时过期时间呢。
本质还是在于热点数据的缓存。减少3方访问以及压力 ，但是第一次访问在所难免
本地缓存使用 - 即便依赖服务不可用 ，我们也要尽量兜底提供服务。
本地缓存 可以做缓存，以及服务调用失败兜底使用 ，比如j2 pod 挂掉了或者redis 服务 短时间不可用， 可以将rocksdb 个人信息数据取出做兜底，第一次查询 ，双写 redis 以及rocksdb ， rocksdb 的 过期时长 为redis 过期时长的一倍（1小时） ，3方服务正常，redis 缓存过期时 ，取 3方缓存，同步redis ，rocksdb。
本地缓存有个问题，所有节点都是无状态的。本地缓存肯定会失效。那么怎么解决这个问题呢， 每次redis 或者数据库成功读取时，异步同步本地rocksdb。
会有大量硬盘占用。
千人千面 ，千人一面
业务场景千人千面，拿不到缓存数据的时候 ，rocksdb 也没有办法去解决 ，这时候 ，果断记录日志 ，根据当前业务场景，判断是否可以通过降级服务去提供服务给调用方使用 。比如 我需要用户nickname ，头像 ，这时候j2 提供不了服务，缓存中也没有。 返回数据中我可以将发送方nickname 设置为兜底数据昵称 朋友 ，并告知前端。 如果前端也设计了降级措施 。
业务场景 千人一面 ，除了redis，就是rocksdb 。 上面说的很清楚了。
网友评论