一直以来对rowkey的设计都比较迷茫，《hbase权威指南》倒是给出了个还算靠谱的例子。
下面这个例子有点儿像帖子表结构，它的rowkey设计是这样的，可以简单的理解为，什么人在什么时间发了什么信息，信息包括什么附件，它是用户为主线的一个设计。
<userId>-<date>-<messageId>-<attachmentId>
如果我们想查某个用户发的信息，我们可以设置scan的start rowkey 为该userId，end rowkey为userId+1即可。
当我们要查某个用户某天发了什么信息，我们可以使用<userId>-<date>来搜索该用户所有的帖子。
当我们要查某个具体的帖子的内容，rowkey过滤<userId>-<date>-<messageId>即可。
所以rowkey的设计是要看具体的应用的。
上面这个例子没有考虑热点的问题，实际上每个用户的帖子被访问的热度是不一样的，有些帖子被大量访问，有的无人问津。
那怎么办呢？有的书上写，在前面加0-n的随机数，random % 机器数 。但是这样子的话，以后你想取某个用户的userId的时候只能开多线程去访问了，因为你不能逆推出来它的rowkey。在和支付宝的工程狮聊了一下，他们是这样处理的取md5(userId)的前4位+reverse(userId)这个样子来处理userId，这样子的话，能解决热点的问题，也可以逆推出来rowkey。
