分布式事务处理方式总结.docxVIP

分布式事务处理方式总结 由于分布式事务比较难于处理，所以应当尽量避开分布式事务的发生。例如对于一个客户信息系统，由于注册用户数太多导致存储的数据量过大，所以对其进行分库分表存储。而客户信息模型又分为多个子模型，对应数据库中的多个表，例如客户基本信息表、客户登录账号表、客户登录密码表、客户联系方式表等等。假设登录账号表和客户基本信息表的关联关系如下所示： user_id和login_id分别是两个表的主键，user_id还作为login_info表的外键使两个表关联。在用户注册时会自动生成user_id和login_id的值。user_info和login_info两个表分别接受user_id和login_id计算分库分表规章。假设我们对每个模型分十库一百表存储，即存在user_info_00 ~ user_info_99一百个表，其中user_info_00 ~ user_info_09属于第一个库，user_info_10 ~ user_info_19属于其次个库，依次类推。在分库分表之后，假如我们不认真考虑user_id和login_id的生成规章(例如任凭生成一个数字字符串或简约使用递增sequence)，就可能导致同一个用户的user_info信息和login_info信息被分别存储到两个不同的库，这就会导致分布式事务发生。面对这种问题，最好的处理思路就是考虑如何避开分布式事务的发生。只需想方法让跟一个用户相关的全部模型数据全部存入到一个库中，就可以避开分布式事务了。由于每个模型数据的分库分表路由规章又是由各个表的主键id打算的(例如user_id、login_id)，所以只需对各个表的主键生成规章进行定制，就可以保证一个用户的全部模型数据全部存到同一个库。假设有下面的id生成规章： 开头的两位是标识模型位，例如user_id以01开头，login_id以02开头。 接下来的11位是sequence递增序列号，假如想要更多的ID可以扩大这部分的位数，但对于存储用户信息而言，11位的长度足够。 接下来是分库分表位，假如每个模型的分库分表算法都相同，那么只需保证每个模型的主键ID的分库分表位都相同，就能保证一个用户的全部模型数据都会存到同一个库中。 最终一位是id校验位，这一位依据前面15位的内容生成，便利对一个id进行校验。 依据这个思想，我们可以在用户注册的时候先生成user_id，user_id的分库分表位可以随机生成。然后在为其它模型生成主键id时(例如login_id)，必需让这个模型的主键id的分库分表位与user_id的分库分表位相同。另外一点也要留意，一个表的查询条件不肯定只要主键id一个，假如有其它查询条件列，那就要保证那一列的生成规章也要包含相同的分库分表位，否则就不能使用该列进行查询。通过这种方式，就可以保证一个用户的全部模型数据全部存储到同一个库中，有效的避开分布式事务的发生。 事务补偿 通常情况下，应对高并发的一个次要手段就是添加分布式缓存(如redis)以提高查询功能。添加分布式缓存后系统查询数据的流程如下图： 即先尝试从缓存中查询数据，假如缓存命中就直接前往结果，否则尝试从DB中查询数据。假如查询DB命中则将数据补充到缓存，以便下次查询时可以命中缓存。而在更新数据时，通常是先更新DB中的数据，DB写入成功后再更新缓存中的数据。那么就有一个问题，如何保证缓存和DB间数据的全都性？由于缓存和DB是两个不同的实体，写入DB成功后再去更新缓存，假如缓存更新失败(例如网络抖动形成短暂的缓存不行用)就会形成缓存和DB的不全都。此时依据上图的查询规律，先查缓存就会查询到“脏”的数据，就会严峻影响业务。这也是一个典型的分布式事务问题——缓存和DB要嘛同时更新成功，要嘛同时更新失败。处理这个问题的一个较好方式就是事务补偿。我们可以在DB中创建一张事务补偿表transaction_log，transaction_log表可以和业务数据在一个库中，也可以在不同的库。在更新数据前，先将要更新的模型数据记录到transaction_log中。例如我们更新user_info表中的数据，就将userId记录到transaction_log中。transaction_log记录成功后，再去更新业务数据表user_info中的内容，最终更新缓存中的userInfo数据。缓存更新成功后，就可以删除transaction_log表中对应的记录。假设在更新完user_info表之后，由于网络抖动等缘由导致缓存更新失败，则transaction_log表中对应的记录就会一直存在，表示这个事务没有完成的一种记录。应用会创建一个定时任务，周期性的扫描transaction_log表中的记录(例如每隔2S扫描一次)。发觉有符