我发起了一个 .Net Core 平台上的 分布式缓存 开源项目 ShareMemory 用于 取代 Redis

Redis 的 安装 是 复杂 的， 使用 是 复杂 的， 

Redis 的 功能 是 重型 的， 

Redis 本身的 技术实现 是 复杂 的 。

 

Redis 是用 C 写的， C 语言 编写的代码需要直接调用 操作系统 底层 API， 如 系统套接字（Socket）， 系统 IO， 这会导致 移植性 兼容性 稳定性 的 问题 。

C 语言 编写的代码是晦涩的，  难以维护的。

 

Redis 是一个 NoSql 数据库， 却被拿来当成 分布式缓存 用，  Redis 里 居然有 “Snapshot”  …… ，  而且 这个 Snapshot 是要写 磁盘 的 。 ……   。

没人知道 Redis 报出的 错误信息 是什么意思，  看到 Redis 的 报错信息，   感觉就像走到了一间 摆满了 老式机器 的 废旧工厂 。

 

所以， 我们应该 把 分布式缓存 和 数据库 这 2 个 职能 从 Redis 里 分解 出来， 用 新的方式 来实现 。

 

1   占用空间小 的 轻量 的 数据 可以存放在 分布式缓存，  轻量 的 数据 比如 用户状态， 业务对象 的 Key（注意只是 Key）， 并行计算 的 状态数据， Token 等，

2   占用空间大 的 “资料性质” 的 重量 的 数据 应该存放在 数据库 。

 

我 建议 能够保存在 本地内存 里的 数据（对象） 不要 放到 分布式缓存， 如果 分布式缓存 只要 保存 业务对象 的 Key 就可以， 那么就只 保存 Key， 而不要保存 业务对象 。 比如， 一些 “秒杀” 的 场景，  要 锁定 被秒杀 的 商品，  实际上只需要 对   商品的 ID（Key）  锁定，  这样在 分布式缓存 里 只要 保存 商品 ID （Key） 就可以，  没必要 保存 商品对象 。

 

可以参考我写的一篇文章 《论 业务系统 架构 的 简化 （二） 用 关系数据库 作 缓存》  https://www.cnblogs.com/KSongKing/p/9928412.html

 

分布式缓存 可以作为 服务器集群 的 共享内存， 也只应该作为 共享内存 这个 角色 。

 

可以再参考我写的一篇文章 《.Net Core 应用方向 图谱》  https://www.cnblogs.com/KSongKing/p/10209880.html

里面提到 ：

MessageRPC 和 ShareMemory 是 我写的 2 个项目， MessageRPC 是一个简单的 RPC，  ShareMemory 是一个 简单的 分布式缓存 。

我现在写的 ShareMemory 这个项目，  可以看作是一个 开始 或者 尝试 。

 

我们完全 可以 开发 一款 轻量化 的 ，  部署简单 ，  使用简单 ， 但是 又能 容易 的 实现 服务器 之间 的 共享数据 的 “共享内存” 的  分布式缓存 。

这款 新的 轻量 的 分布式缓存 ，  由 .Net （.Net Core） C#   开发编写，

代码 和 平台  清晰透明，     容易理解 和 维护 。

 

分布式缓存 会 涉及 Hash 表， 可以参考 《自己写一个 Hash 表》  https://www.cnblogs.com/KSongKing/p/10425152.html  。