ca面试是什么,java分布式面试问题

　　00-1010简介1。面试官，说到CAP定理，能详细说说CAP代表什么吗？2.面试官：听起来很简单。只是一个概念，但具体指什么？结合实例进行深入分析和总结

　　00-1010上一节我在面试中被问到分布式系统的概念。说完分布式系统和RPC的概念和优缺点，我以为这个问题就结束了。没想到成功给自己挖了个坑(笑脸)。关于CAP，以前只听说过，没有详细整理过。这一次，我约出来了。

　　CAP已经成为计算机科学的一个研究领域。当我们谈到分布式系统的优势时，我们谈到了三个改进：

　　1.提高了系统可用性。

　　2.提高系统的并发性。

　　3.提高了系统的容错能力。

　　那么这三个方面在实施中能同时满足吗？答案是否定的，在设计分布式系统的时候，设计师需要了解一个重要的理论概念，CAP定理。

　　00-1010问题分析：经典的概念性面试题。

　　a:关于CAP，是2000年7月加州大学伯克利分校的Eric Brewer教授在ACM PODC会议上提出CAP猜想。两年后，麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP。之后，CAP理论正式成为分布式计算领域公认的定理。

　　C的拼写是Consistency，意思是一致。

　　A的拼写是Availability，意思是可用性。

　　p的拼写是Partition tolerance，意思是分区容错。

　　00-1010问题分析：这种问题不能等面试官下次再问。这次面试感觉像挤牙膏。要不我一口气说完，让面试官闭嘴？

　　答：分布式系统最多能满足三项中的两项：一致性、可用性和分区容忍度。

　　同时满足一致性(C)和可用性(A)需要牺牲容错性(P)，同时满足可用性(A)和分区容错性(P)需要牺牲一致性(C)，分区容错性(P)需要牺牲可用性(A)。

　　(开始拿起笔和纸画三个圆圈)

　　这三个象限只能满足两个圆相交。

　　面试官：好了好了，这个理论问题到此为止。时间有限。说点别的吧。

　　00-1010使用Redis集群高可用架构举例：Redis可以将数据切片成多个实例(按槽存储)，即一个机房共享部分数据。主机负责写，主机会自动同步到从机。

　　Redis分散式集群架构的优势：

　　1.无中心架构：部署三个机房，其中一主一从形成一片，数据在它们之间通过异步复制同步。异步复制存在数据不一致的时间窗，保证高性能的同时牺牲了一定的一致性。一旦一个机房断开连接，位于片上另一个机房的从机将被提升为主机，以便它可以继续提供服务。

　　2.可扩展性：可以线性扩展到1000个以上的节点，可以动态添加或删除节点。

　　3.降低运维成本，提高系统的扩展性和可用性。

　　分析一下，CAP中的哪两个定理在这种分布式架构下满足？

　　如优势1所述，部署三个机房，每个机房有一个主机和一个从机，即一个主机对应一个从机。但是你会发现，机房1的主机1连接的从机在机房2，机房2的主机2连接的从机在机房3，机房3的主机3连接的从机在机房1，这样就形成了一个环。为什么要这样设计？

　　假设：停电或者机房失火或者其他原因，反正1号机房的机器都用不了。

　　这个时候1号机房的所有数据都无法访问？这显然是我们不想要的。前面已经说了，主机负责写，主机会自动同步到从机。如果Master的写服务宕机，Slave的读服务就会升级为Master，也就是说1号机房的数据还备份在2号机房的Slave2上，数据还在。Slave在down Master恢复之前要同时承担读写服务，虽然有点累，但还是可以用的。这种设计旨在提高可用性(A)和容错性(P)。系统允许你关闭一台机器或者整个机房，系统仍然可以使用。

　　但是你会发现，如果单个机房比较远，Master1到Slave2的数据同步是跨机房的，跨机房同步肯定和机房块不一样，所以Slave2负责读取，Master 1要更新的数据没有同步到他在另一个机房的备份，所以读取操作不一致。

　　计显然是牺牲掉一致性（C）。相信这样分析应该能理解 CAP 定理了。

　　进一步分析：

　　让同一组 Master - Slave 放在一个机房，同机房复制数据不是更快？这样能不能解决数据一致（C）问题，答案是能，还有更好的解决一致性的办法就是不要 Master - Slave 组合，就一台机器，一台机器同时担任读写请求，没有延迟不存在数据一致性问题。这是时候如果宕机了怎么办？这样的架构下，那就真的是不可用了，解决了一致性（C）却牺牲了可用性（A）和容错性（P），太不划算了。

　　总之，分布式系统下，CAP 确实无法同时满足，在 Redis 去中心集群架构中，最优的解决方案还是满足可用性（A）和分区容错性（P）就要牺牲掉一致性（C），即使跨机房同步数据，延迟也不过 1s，数据不一致的问题只出现在 1s 内，日常开发中，很少遇到要求强一致性的场景。例如订单系统，用户更新了订单支付状态，读订单状态是在从库，有什么读场景等不来这一秒？

　　如果真的必须要求强一致性，那可能就必须调整分布式架构方案来。

总结

本文主要讲解了 CAP 定理的概念，为什么要学习这个概念，设计高可用分布式系统时，你必须知道系统的短处，懂得 CAP 能让你根据实际情况有舍有得。面试会被经常问到，比如，你说你使用了消息队列，解决了系统耦合问题，提高了响应速度，那面试官问题：使用消息队列有啥缺点？如果你知道 CAP 定理这个问题还难吗？

　　显然消息的延迟会带来数据不一致问题。理想情况下消息不丢失那数据会最终一致，你能保证消息不丢失吗？如何解决机问题，如果是我，我会选择 最终一致性，就是说不管消息延迟多久甚至丢失，设计一个离线定时任务，定期去扫描两个系统的数据，有不一致的情况就主动刷新同步，这样保证最终一致。

　　以上就是java分布式面试CAP分别代表含义分析的详细内容，更多关于java分布式面试CAP含义的资料请关注盛行IT其它相关文章！

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。