接前文
http://blog.itpub.net/29254281/viewspace-2113781/
作为直播类型的应用.
采用最终一致性处理用户发送礼物和接收礼物.
发送礼物是同步的,接收礼物是异步的.
那么如何得知主播(收礼者)的真实帐号金额呢
因为总有一部分主播的银子,尚在处理之中,没有增加到主播的帐号里面.
其实用Redis也可以解决这个问题.
发送方事务完成之后,更新redis,把本次事务信息写入redis
接收方异步处理.
等接收方主要流程结束,事务提交之前,操作Redis
删除之前发送方处理流程记录的Entry.
将发送方余额写入固定的key
这两步Redis操作可以合成一个Redis事务.
获取主播的真实帐号余额,HGetALL,应用程序慢慢算好了.
异常流程
1.发送方更新Redis失败.(该事务TranslogID的entry没有写入成功)
由于最终一致性,待接收方处理的时候,余额最终也会加上
2.接收方更新Redis失败.
待下次收礼 或者 Redis key超时.
更新主播帐号余额,因为有数据库锁保护.所以没有并发问题.
每次开播之前,都将主播的这个信息初始化.超时时间5分钟.
http://blog.itpub.net/29254281/viewspace-2113781/
作为直播类型的应用.
采用最终一致性处理用户发送礼物和接收礼物.
发送礼物是同步的,接收礼物是异步的.
那么如何得知主播(收礼者)的真实帐号金额呢
因为总有一部分主播的银子,尚在处理之中,没有增加到主播的帐号里面.
其实用Redis也可以解决这个问题.
发送方事务完成之后,更新redis,把本次事务信息写入redis
接收方异步处理.
等接收方主要流程结束,事务提交之前,操作Redis
删除之前发送方处理流程记录的Entry.
将发送方余额写入固定的key
这两步Redis操作可以合成一个Redis事务.
获取主播的真实帐号余额,HGetALL,应用程序慢慢算好了.
异常流程
1.发送方更新Redis失败.(该事务TranslogID的entry没有写入成功)
由于最终一致性,待接收方处理的时候,余额最终也会加上
2.接收方更新Redis失败.
待下次收礼 或者 Redis key超时.
更新主播帐号余额,因为有数据库锁保护.所以没有并发问题.
每次开播之前,都将主播的这个信息初始化.超时时间5分钟.
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/29254281/viewspace-2119986/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
同步写两个数据库--多线程
下一篇：
常见的排序算法
请登录后发表评论
登录
全部评论
