这是我参与「第五届青训营」伴学笔记创作活动的第 9 天
本节重点
通过对拜占庭将军问题的思考，能够对“共识”有更加深刻的理解。
问题描述
看完问题描述后，首先的思考：
对于方案一，无法 100% 达成共识，只能够提升概率，理论上无法解决问题。
现实生活中主要采用的方案二，其实不难发现，这一方案和 TCP 协议非常像，但是不同的地方在于 TCP 协议保证的是数据传输，而现在是要达成共识，这是有一定区别的。TCP 往往是通过三次握手加超时重试去解决问题，这是一个工程解法，但是并非理论解法。
回到问题本身，我们可以看到将军 A 和将军 B 先建立一个连接，派出一个连接的信使，然后再派出一个真正的信使，最后关闭这个连接最后双方能接近的达成共识。所以从后面的章节，可以说如果两个节点需要通讯的话，TCP 其实就已经可以近似解决了双方共识的问题。
再思考，为什么 TCP 是三次握手而不是两次或四次？握手过程中如果 FIN 报文丢失，怎么办？
下面更加普适地看待拜占庭将军问题：
其实不难看出，拜占庭将军问题是一个很难处理的问题，但其实在实际分布式系统中，绝大多数系统都不是去解决拜占庭问题；但正儿八经地把这个问题看得很重要的是比特币，比特币其实就是一个拜占庭容错的一个系统，这里就不展开赘述了。
在分布式系统中，其实可以通过纠错的方式，如增加冗余信息来对信息进行加密来保证消息的不被篡改。正式的分布式场景，都不太会去考虑消息是否被篡改。
阶段小结
从以上思考可以看出，想要达成 100% 的共识是非常之困难的，只能说是一个将概率趋向于 1 的过程。当然，虽然在我们实际后端开发过程中，这并不是我们需要去考虑和解决的问题，但是我们还是要对这一概念有所了解。
