分布式事务
说到区块链的分片,我想到了原来分布式数据库处理事务的方式。
例如账户A的数据在机器1上，账户B的数据在机器2上，
A->B转账，怎么把这笔转账做成事务(A扣钱，B加钱要么同时成功，要么同时失败)
有两种做法，一种叫做两段式提交(甚至多段提交)，这种方式储存的是账户的状态
另一种是事件驱动(Event driven)，也就是只要系统中存好转账请求的顺序，就算这笔转账成功，
这种方式储存的主体是转账请求。
之前听过支付宝OeanBase的技术分享，他们是从方法一进化到方法二的，
大概是因为方法一性能比较差(需要加锁)，需要处理的特殊情况多(死锁和失败等一系列问题)等一系列劣势。
我说分布式事务，其实是觉得他和区块链之前有很强的联系。可以互相借鉴
比特币，其实是第二种做法，是以交易为存储主体的，但是不同的是他的数据没有分片的，所以处理起来比较简单。
以太坊，我的理解是第一种做法，以账户状态为主体，但也是没分片的，所以也是直接处理。
(这里讲的处理，是指判断一个交易是否合法，更具体一点，A->B赚钱，A的账户是否钱足够)
区块链如果想要数据做分片，首先要能确保一点：
针对某一个账户，整个系统能对所有从那个账户转出的钱的交易和交易的顺序有一个共识，就可以了。
另一种说法: 系统对A->B(B是任意其他账户)的交易顺序有一个共识。
既然要做分片，那么存储和验证都要做分片，交易顺序应该由响应的验证节点分片来完成
其次要确保能查到B增加的钱:
比如B需要赚钱给C的时候，验证节点需要知道B的账户里是否有足够的钱(有多少钱)
如果验证节点的状态以账户状态为主，那么需要保证A(任意节点)->B的转账，金额在很短的一段时间内要能加到B账户里，
如果验证节点的状态以交易为主，那么需要保证，A(任意节点)->B的转账，能在很短的时间内查到(比特币SPV的原理)
这点我觉得是这里面比较有挑战的事情(要么涉及到分布式事务，要么涉及到能非常高效的查询(查询B所在分片之前不知道的新的X->B的交易))
魔兽世界后端的分片
魔兽世界里的一个城堡里，可能有成千上万的人。而你在魔兽世界的城堡里走动的时候，并没有看到那么多的人，这是为什么呢？因为魔兽世界采用的是平行世界的方法, 只保证你能看到和你有过密切互交的玩家，例如你刚和他聊过天，或者交易过，之类的玩家，当然也有一小部分随机玩家。你看到的人，只是这个世界的一个子集。
这种思路也可以在区块链分片中应用：把互相转账比较高的用户尽量放到同一个区域(例如使用同一个Dapp的用户)
魔兽世界的地图也是分块加载的，只有你到达了这一块地图的的边缘，才会加载临近区域的地图。
这可以类比区块链里的存储分片
基于账户的树形分片
我现在觉得比较可行的方案: 4个区域的例子
level0 A|B|C|D
level1 A|B C|D
level2 A B C D
交易(X->Y)根据转出者X，Y分到相应分区, 每个分区做交易的共识
