关于缓存的一种想法

一般做缓存，都是针对大并发下，数据交互产生效率问题，从而考虑做缓存，缓存的选择也有很多种，比如，一种常见的数据tt_tc，他被用作做网站数据库的缓存数据库，主要是一个key-value store，可能是hash算法比较快，从而很容易找到对象，提高访问效率，他也有很多种存储结构，即支持不同类型的数据库，供人们选择。

迄今为止，笔者看到的数据库存储结构不多，但二维表、对象、xml好像比较流行。

在网站上比较流行的是json字符串传输，那么，我们可以把缓存结构设计成存储json字符的结构。即专门针对json的存储库。

更通用的，即是编写一个专门针对json格式的数据库。

如｛a:{b}｝,再存一个，就直接在后面加上字符串，｛c:{d}｝,这样整个结构也可以看成是一个大对象。

可以认为：它应该符合以下几个特点：

1，它有对象的概念，因为每个字符串都代表一个对象，也包含了其他子对象。

2，它应该有编码的概念，否则，无法让大家认识到字符串的编码。（可以考虑全部转换成utf-8存储）

3，实现所有的对象也都放在一起的这种结构，即总的存储也是一个json串

4，针对这种结构，查询则很难。需要一个合理的算法来进行删查改。

     这个地方应该是关键，比如，每场增加一个，就需要对它的结构分析一下，在另外一个文件存储的存储次序及相应的子结构，并建立一个地址索引，方便，存储对象被定位，但这个设计，算法上要保证查找地址的速度，否则，整个设计都归于失败。

5，显然存储是最简单的，因而效率应该是最高的。

6，提供加锁的功能。

7，不提供安全，事务功能，这种结构好像不合适。

8，显然支持数据移动，最好不记日志。

9，提供一个网络接口，供别人访问，不知有没有符合 这种结构的协议。

如果满足这几点，应该可以胜任一些数据缓存的工作，但最好可以支持分布式，即多个结点相互同步，另外它不支持二进制

信息存储。只支持对象里只包含基本数据类型的时候。因为大数据量会影响速度。

如果谁有精力，可以想想有没有必要实现，另外，可以考虑怎么去实现。给点意见。