我发起了一个 .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  。

 

原文地址:https://www.cnblogs.com/KSongKing/p/10213051.html