java项目开发实例 java系统架构有哪些( 三 )

硬件的第二个问题是，硬件不是 100% 的可靠，它本身也会出问题。
比如说，服务器断电了，网络电缆被挖断了，甚至是各种自然灾害导致机房整体不可用。尤其是一个大型系统，服务器规模很大，网络很复杂，一旦某个节点出问题，整个系统都可能受影响，所以，机器数量变多，也放大了系统出故障的概率，导致系统整体的可用性变差。我们在做技术架构设计时，就要充分考虑各种硬件故障的可能性，做好应对方案。比如说针对自然灾害，系统做异地多机房部署。
软件的问题接下来我们说下软件的问题，这里的软件，主要说的是各种中间件和系统级软件，它们配合我们的应用代码一起工作。
软件是硬件的延伸，它主要是解决硬件的各种问题，软件通过进一步封装，给系统带来了两大好处。
首先是弥补了硬件的缺陷。比如 Redis 集群，通过数据分片，解决了单台服务器内存和带宽的瓶颈问题，实现服务器处理能力的水平扩展；通过数据多副本和故障节点转移，解决了单台服务器故障导致的可用性问题。其次，封装让我们可以更高效地访问系统资源。比如说，数据库是对文件系统的加强，使数据的存取更高效；缓存是对数据库的加强，使热点数据的访问更高效。但软件在填硬件的各种坑的同时，也给系统挖了新的坑。举个例子， Redis 集群的多节点，它解决了单节点处理能力问题，但同时也带来了新的问题，比如节点内部的网络有问题（即网络分区现象），集群的可用性就有问题；Redis 数据的多副本，它解决了单台服务器故障带来的可用性问题，但同时也带来了数据的一致性问题。
我们知道，分布式系统有个典型的 CAP 理论， C 代表系统内部的数据一致性， A 代码系统的可用性， P 代表节点之间的网络是否允许出问题，我们在这三者里面只能选择两个。对于一个分布式系统来说，网络出问题是比较常见的，所以我们首先要选择 P ，这意味着我们在剩下的 C 和 A 之间只能选择一个。
CAP 理论只是针对一个小的数据型的分布式系统，如果放大到整个业务系统， C 和 A 的选择就更加复杂了。
比如有时候，我们直接对订单进行写库，这是倾向于保证数据一致性 C ，但如果数据库故障或者流量太大，写入不成功，导致当前的业务功能失败，也就是系统的可用性 A 产生了问题。如果我们不直接落库，先发订单数据到消息系统，再由消费者接收消息进行落库，这样
即使单量很大或数据库有问题，最终订单还是可以落地，不影响当前的下单功能，保证了系统的可用性，但可能不同地方（比如缓存和数据库）的订单数据就有一致性的问题。
鱼和熊掌不能兼得，系统无法同时满足 CAP 的要求，我们就需要结合具体的业务场景，识别最突出的挑战，然后选择合适的组件，并以合理的方式去使用它们，最终保障系统的稳定运行，不产生大的业务问题。

以上关于本文的内容，仅作参考！温馨提示：如遇健康、疾病相关的问题，请您及时就医或请专业人士给予相关指导!

「四川龙网」www.sichuanlong.com小编还为您精选了以下内容，希望对您有所帮助：