@documentzhangx66 我目前就在开发一个支持分布式的服务。客户端会与服务进程通信,服务进程从 redis 获取用户 session 信息,以及上报当前 session 的一些数据到 redis 。还有个管理进程去维护 redis 中的数据,最终数据都是存放在 mysql 中的。
服务进程中有使用 map 进行 redis 数据缓存,曾经实测过每次收到客户端数据时都通过 TCP 连接从 redis 拉取客户端数据,结果是会严重影响性能。而且因为是单 TCP 连接 redis(设计成多连接又会继续增加复杂度),redis 请求需要类似 HTTP 那样按顺序处理,会导致无法并行处理客户端数据。
所以 map 比 redis 性能好时,为什么还要使用各种类型的数据库呢?因为有别的需求,仅用 map 不能满足这些需求。不能不看需求就认为不能用 map ,而且即使用了 redis ,本地也适合用 map 再增加一层缓存。
比如说上述案例,如果改为全都直接读 SQL 数据库,SQL 数据库没有通知客户端缓存失效的接口。如果管理进程和服务进程通过 RPC 通信来交换数据,那基本等于重新实现了 redis 的功能,又要写很多 RPC 通信的代码,管理进程崩掉也会影响服务进程正常工作,还不如直接使用 redis 。