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

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

https://segmentfault.com/q/1010000006095431

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

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

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

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

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

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

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

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

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

展开阅读全文

没有更多推荐了,返回首页