工程开发中的“事务”

背景

前段时间读了一篇文章《程序员，你应该知道》，里面有说“事务”这个东西，意思是生活中有许多事务。比如，你去超市买了一包5毛钱的方便面，给了收银员1块钱，收银员找回你5毛钱，这就是一个事务。

我当时没有太理解。

从一次服务重构说起

最近有一个发号器服务，为了支持分布式部署，提升服务性能，所以进行了一次重构。重构过程中，我没有考虑机器宕掉对服务的影响。开发完，测试之后上线了。

在公司楼下闲聊的时候，一个同事问我，你的服务如果机器宕掉了会有影响吗？我果断的说，会。（因为设计的时候我根本就没有考虑这个事情）

回答问题之后，我就在心里揣摩这个事情。

我们这个体量的公司，需要考虑机器宕机这种场景吗？我觉得不是太需要。

但是既然谈到事务，就来细致的分析一下这个问题。

 

机器宕机了，对我的这个服务有什么影响？

机器宕机之后，用户会得到失败的响应，服务内部临时存储还没保存的数据会消失。虽然这部分数据在redis里有一份，且redis里的数据暂时不会丢失，但是服务里没有从redis刷数据到HBase这个步骤。

所以，在缓存过期之后，用户再次请求，会得到和之前不一致的数据。

这一套流程，可以说，机器宕机导致的后果很严重，且宕机后出现的问题不易快速恢复。

用户请求数据到收到响应，这应该是一个事务。

对于服务，返回给用户的结果不一定是成功的，符合预期的。但是得保证，用户在一次请求失败之后，再一次发起请求，第二次的请求结果不应该受前一次或者前N次的错误影响。

总结

重复一下事务的特性：原子性、一致性、隔离性、持久性。

此时，我有些明白了。

回到开始的问题：服务设计的时候需要考虑宕机的场景吗？

答：对于体量不那么大的公司，可以接受机器宕机导致的服务不可用。但是不能接受因为机器宕机导致服务的数据不准确。