谈谈业务中使用分布式的场景

###谈谈业务中使用分布式的场景

https://blog.csdn.net/wuzhiwei549/article/details/79787866

https://segmentfault.com/q/1010000006095431

1首先，需要了解系统为什么使用分布式。
随着互联网的发展，传统单工程项目的很多性能瓶颈越发凸显，性能瓶颈可以有几个方面。
一、应用服务层：随着用户量的增加，并发量增加，单项目难以承受如此大的并发请求导致的性能瓶颈。
二、底层数据库层：随着业务的发展，数据库压力越来越大，导致的性能瓶颈。
针对上面两点，我觉得可以从两方面解决。
应用服务层：
应用服务层的解决方案有几种：
应用系统集群：
应用系统集群最简单的就是服务器集群，比如：tomcat集群。应用系统集群的时候，比较凸显的问题是session共享，session共享我们一是可以通过服务器插件来解决。另外一种也可以通过redis等中间件实现。
服务化拆分：
服务化拆分，是目前非常火热的一种方式。现在都在提微服务话。通过对传统项目进行服务化拆分，达到服务独立解耦，单服务又可以横向扩容。服务化拆分遇到的经典问题就是分布式事务问题。目前，比较常用的分布式事务解决方案有几种：消息最终一致性、TCC补偿型事务、尽最大能里通知。具体的你可以参考下这篇博客分布式事务解决方案
底层数据库层：
如果系统的性能压力出现在数据库，那我们就可以读写分离、分库分表等方案进行解决，由于这方面我的经验也不够多，所以，你可以参考下其他的一些文献。

2不过据我了解，技术面试一般都是层层渐进，面试官试探候选人技术体系的深度，所以说理论上在一个话题上聊的越多，越代表候选人的能力越优秀。很多高并发和分布式的处理问题其实都是经验问题，因为不同业务场景不同数据量的高并发处理情况完全不同，并没有完全通用的解决方案。

所以面试的时候，理解面试官描述的业务场景非常重要，这也是分析性能瓶颈的关键信息，根据木桶原理，肯定在某一个关键点存在瓶颈。

举个简单例子，随着业务增长，一个直连数据库的服务器集群遇到了性能瓶颈，应该怎么解决？

这个时候你要首先分析性能瓶颈出在哪里，首先，要考虑数据库本身的设计是否合理，索引是否起到了作用，分析SQL执行计划，是否可以把数据库进行水平拆分或者垂直拆分来分摊压力。

进而还要分析能否使用分布式的读写分离数据库，引发怎么进行数据同步，数据分发的问题等等。

数据库层分析完之后，在应用层也可以分析，一般是通过缓存来提高查询性能，涉及缓存的命中率问题，缓存的更新问题，缓存的多节点 hash 问题等等。

总得来说，要搞清楚业务场景，然后针对某个具体的问题，去尝试提出解决方案。比如新浪微博，是采用推模式还是拉模式？如果是推模式的话，一个几千万粉的大v发条微博，是不是要给这几千万人推？如果是拉取模式，一个人关注的用户多了每次拉取的时候会不会出现性能问题？

3分布式有很多种，比如你把你的项目分成了多个模块，每个模块一个jvm 通过rpc调用来完成整体的工作，这是分布式，比如你redis单台无法抗那么多并发或者无法有那么多内存做缓存，可以做redis集群，这也是分布式，再比如，你的数据库单台无法满足你现在的数据量或者并发量，那么分库分表，通过jta实现事务这也是分布式，再加上什么日志同步，负载均衡，加hdfs存储数据备份，存储日志，加eslaticsearch 分析搜索日志 都可以谈。