分布式事务处理方式总结
|
于在分布式系统中，多个系统无法共用同一个数据库链接，所以无法简单借用上面的处理方式实现分布式事务。 下面将介绍几种本人在实际开发中使用过的处理分布式事务的方式，最后再引出分布式事务的相关理论并进行总结。 避免出现分布式事务 由于分布式事务比较难于处理，所以应该尽量避免分布式事务的发生。例如对于一个客户信息系统，由于注册用户数太多导致存储的数据量过大，所以对其进行分库分表存储。而客户信息模型又分为多个子模型，对应数据库中的多个表，例如客户基本信息表、客户登录账号表、客户登录密码表、客户联系方式表等等。假设登录账号表和客户基本信息表的关联关系如下所示：户注册时会自动生成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)，所以只要对各个表的主键生成规则进行定制，就可以
根据这个思想，我们可以在用户注册的时候先生成user_id，user_id的分库分表位可以随机生成。然后在为其它模型生成主键id时(例如login_id)，必须让这个模型的主键id的分库分表位与user_id的分库分表位相同。另外一点也要注意，一个表的查询条件不一定只有主键id一个，如果有其它查询条件列，那就要保证那一列的生成规则也要包含相同的分库分表位，否则就不能使用该列进行查询。 通过这种方式，就可以保证一个用户的所有模型数据全部存储到同一个库中，有效的避免分布式事务的发生。 事务补偿
通常情况下，应对高并发的一个主要手段就是增加分布式缓存(如redis)以提高查询性能。增加分布式缓存后系统查询数据的流程如下图： （编辑：泉州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
