<第一周>key-value数据库集群的发现与思考（兼锻炼坚持能力）

Ok, it's getting intensive now. Be warned, this is going to cause a lot of headaches, :-).

I can't type in chinese, even if I could, I can type only as slow as a turtle, so bear with me.

I had two posts, one is here: http://jellyfish.iteye.com/admin/blogs/100840
another is here:
http://www.cjsdn.net/post/view?bid=62&id=195175&sty=1&tpg=1&age=0

Updates:
1. tried Terracotta, if we go to distributed, then it's commericial. There was a war going on between Terracotta and Tangosol(looked like Terracotta started it). From the exchange fire, I sensed that Terracotta is far behind(~4 years behind).

2. I suddenly realized that the lock has to be distributed as well. Damn, more salts on the wound.

3. Here is the list of the rest features I think are useful(copied from the cjsdn link)

-----------------------------

If I understand the distributed cache correctly, the following are the key points on a distributed cache solution:
1. clusted: all different JVMs carry the same content, replicated.
2. fault tolerant: >1 copies in the cache. Normally this feature and #1 are implemented as one, i.e., users can specify how many copies they want in the entire cache.
3. scalable: meaning, increase machines/JVMs to expand memory, not copies. Whether this is transparent to the users, i.e., whether users need to change code for new cache servers.
4. network protocols: UDP/TCP
5. transactions
6. backup to files/databases asynchronously.
7. API for other languages, JDBC/ODBC drivers
8. SQL language manipulations.
9. near cache/far cache memory management.
10. locking
11. distributed event handling, such as JMS. This is essential for intersystem updates.

A big memeory cache is on the main course because db is limited and slow without customization. Hooking a lot of small machines into a gaint memory is the way to go. Google and Tangosol did it right. But the idea is way old. I used to play a game called MOM(master of orion, version 1, dated earlier 90's), it used the same idea, build thousands of small ships and stack them together to form a gaint monster. I talked with my fellow gamers about this idea, someone would do it right one day.


just my experience, hopefully this is useful for you(or scare you away from it, :-)).

根据CAP理论，Consistency(一致性), Availability(可用性), Partition tolerance(分布)这3点最多只能满足2点。感觉楼主的说法是打算寻找一个3者全部满足的方案，但是目前还真没有这样的方案。目前的案例大多是采用牺牲C以满足分布要求，没有专门的事务API帮忙，只能你自己编码实现柔性事务。
现在基本上是小型系统牺牲P，大型系统牺牲C。