/** 
 * Roster item cache - table: key jabberid string; value roster item.
 */  
protected ConcurrentHashMap<String, RosterItem> rosterItems = 
     new ConcurrentHashMap<String, RosterItem>();

/**
 * remove a jid from a list, returning the new list
 *
 * @param id the JabberID that should be removed
 * @param ids the list of JabberIDs
 * @return the new list
 */
static jid _mod_presence_whack(jid id, jid ids) {
       jid curr;

       if (id == NULL || ids == NULL)
       return NULL;

       /* check first */
       if (jid_cmp(id,ids) == 0)
       return ids->next;

       /* check through the list, stopping at the previous list entry to a matching one */
       for (curr = ids; curr != NULL; curr = curr->next) {
       if (jid_cmp(curr->next, id) == 0)
           break;
       }

       /* clip it out if found */
       if(curr != NULL)
           curr->next = curr->next->next;

       return ids;
}

需要一个pubsub的功能，用在基于各种好友关系的场合。

* publish list 可能成千上万、十万、百万。
* publish topic 生命周期可能极短，调用一次就结束；也可能很长
* publish 数据实时广播即可，无需保存等待consumer到来
* subscribe list 可能很长，大的数千，也可能很小，只有1个
* subscribe list 相对固定(在线好友列表 or follow list)
* subscribe list 需要跨节点的，即一个topic在多个节点有local subscribe list
* 对性能要求极高，性能为王
* 无事务要求，特殊状况下，如某节点发生故障，丢失小量数据可容忍。
* 分布式，无中心节点
* 节点可动态切换

目前还没找到适合我的现成产品。前几天提到的rabbitmq和erlang或许是一个思路。

Erlang太高深了，周末的时候想了一个适合各种小白语言的思路，试画了一个简单的。

在大型的应用中，我们经常碰到MySQL的表数据需要无限扩充的情形。我们通常有以下一些解决方案，但是现成的方案都不是完美的。

比如，
MySQL master/slave: 只适合大量读的情形，未必适合海量数据。
MySQL cluster: 提供的可能不是大家想要那种功能。
MySQL proxy: MySQL master/slave配合
MySQL 5.1 partition: 只是将一个表存储上逻辑分开，部分改善了性能，但是可扩展性仍然是问题。
MySQL 按应用逻辑分表和分数据库，通过程序来决定数据存放的表，目前很多公司都是这么做的。它的主要问题是跨区查询，可参考Tim以前的文章MySQL分表实现上百万上千万记录分布存储的批量查询设计模式

使用程序来分表分服务器最大的问题是比较繁琐，需要程序做很多特殊处理，需要程序员了解数据存放在哪个服务器哪个表，这样，几乎所有的程序员都牵涉了进来， 也容易出错。那如果我们把分表的逻辑放到中间层则上层的应用就简单很多，而且可以单点控制分表的逻辑，方便调整与扩展。

HSCALE分表分数据库的思路

HSCALE就是这样一个产品，它是在MySQL proxy的 基础上，在MySQL proxy的层面将上层的请求分配到实际的表上。实际的原理是通过拦截SQL进行替换和服务器重定向再将SQL传递到目标服务器上。它的分表算法可以由自定义的Lua脚本来实现，非常灵活。目前已经能支持同数据库分表，跨数据库的实现也将增加，因为在MySQL proxy的框架下，这并不是很困难的事情。现在的版本或许不是很成熟，但是在原理上我觉得是基本上没多大障碍，发展下去将是一个不错的选择。

HSCALE具体的性能测试简单介绍如下。

• 测试

使 用HSCALE有2个开销，一是网络层面的，下面的测试环境大约MySQL proxy对每个SQL会增加0.02ms的网络延迟，如果增加了HSCALE, 则会增加到0.3ms，第2个开销则是MySQL proxy, Lua, SQL解析，HSCALE算法等造成，可看下面数据。

• 测试数据一

(图片来源：pero.blogs.aprilmayjune.org)

结论是最极端的情况下，在10个线程的情况下，使用MySQL proxy会需要大约3倍时间，HSCALE则是10倍。
注意结论是MySQL方面最优化的情况，查找一个三条记录的表。在实际环境中的latency和这个没有直接比例关系(比如1:3)。测试结果不太令人满意，幸好后面新版本MySQL proxy的测试数据得到了改善。

• 测试数据二

使用了MySQL proxy 的 svn版本，性能提升很大。MySQL/MySQL proxy从1:3提升到1:2, HSCALE同样也提升比较大。具体结果见连接。但是仍然迫切希望作者再有提升。

今天说到大部分技术Blog都以介绍国外技术与产品的文章为主，没有深度，当然我这篇也不例外。:)