解决高并发问题不只有分布式

学为所用

已于 2022-08-09 17:58:58 修改

阅读量519

点赞数 1

分类专栏：服务架构文章标签：高并发分布式

于 2022-08-09 17:57:41 首次发布

本文链接：https://blog.csdn.net/yyykj/article/details/126246389

版权

服务架构专栏收录该内容

5 篇文章 0 订阅

订阅专栏

解决高并发问题不只有分布式

互联网技术圈的普遍现状
业务代码中影响并发的因素浅析
写在后面

互联网技术圈的普遍现状

互联网的高速发展，也带动了相关技术领域研发人员的快速增长和新技术的快速迭代。但在国内的互联网技术圈中，大量的使用了国外的框架及各种成品、半成品项目进行开发，已经很少有人基于业务需求从基础针对性设计开发了。表面看是为了快速实现项目，但是实际上总的研发成本和运营维护成本急剧上升，最终到项目稳定所经历的周期并没有缩短，尤其对初创项目的危害更加明显，具体原因另文分析。

由于大量的照搬别人的项目，没有在架构设计上针对性的优化数据格式、减少传输量、减轻计算处理资源消耗，造成单个请求处理时间过长，占用资源过多，从而使高并发问题突出。于是很多技术负责人就决定使用分布式扩充资源的方式提高并发性能。但是这给运营维护成本和研发人员成本都是不小的增加，时间稍久可能就突破了一个初创公司的承受极限。

从技术角度讲，往往采用了分布式扩容后，对用户体验也没有明显增加。究其原因就是架构设计中数据处理链条过于繁重，单个请求占用资源过多，所以再怎么扩容都改变不了单个请求慢的根本原因。
.

业务代码中影响并发的因素浅析

下面就分布式技术之外的，对并发影响明显的几个方面做一下简要叙述，这是本人多年实践经验所得，并非出自某个名家的理论，若不认同请一笑而过！

1、尽量减少数据库查询使数据静态化

网络应用最容易出现瓶颈的地方就是数据库访问，提高数据库的访问速度和减少访问次数都是十分必要的优化手段。其中数据库查询是对数据库最频繁的操作，所以减少查询次数对提高并发性能十分明显。

对于更新频率十分低的数据（如地址名、分类名、单位名、已发布的信息与评论、非即时统计结果、状态等等），采取数据库中与文件双重保存的方式，使数据静态化。在内容更新时同步更新文件。静态化的方法虽然老套，但是十分有效。

2、WEB页面静态化

对于WEB应用，动态页面的输出合成过程，相对于静态文件是比较耗时和耗费资源的。大部分页面是更新频率极低的，可以将这部分页面直接合成文件保存，有需要更新的时候，同步更新这个文件即可。这样会提速很多，还是那句话，静态化的方法虽然老套，但是十分有效。

3、充分利用内存型数据库缓存数据和页面

经过静态化的数据或页面，在磁盘上读取的速度还是没有内存中快，所以条件允许的情况下，尽量将常访问的数据或页面缓存到内存型数据库中，这样会大大提高静态文件的读取速度，提高并发性能。

4、压缩API传输的字节数

现在API接口交互的数据基本都是JSON格式的。如果继续使用JSON格式，那建议简化键名，最好使用1-2个字符来描述即可。至于有人说易读性不好，我想说这个名字是给开发人员看的，开发人员一个对照表（开发文档或工具）就可以搞定，为什么要让传输数据臃肿给应用运行带来额外的负担呢。

再者可以抛弃JSON格式，使用自定义格式，更加降低传输量。这也有人会说JSON是标准，服务器资源那么多为啥做这个改动使开发效率降低呢。我想说的是，并发问题是什么，本质就是积少成多的堆积，一个两个请求不觉得，多个挤在一起就显示出访问处理速度、传输速度的重要性了。这对服务器性能和网络带宽要求都是有直接影响的。至于说开发繁琐，只能说如果这样认为，那是没有真正实践过，当真正实践成功过后，会发现并不繁琐，反而有很多优点。至于标准，如果是自己的应用接口，不是对外的公共接口，符不符合JSON标准又何妨呢？反倒觉得这样更安全呢！

这个观点可能会有很多人喷我，但请大家理解任何技术变化都是有他的应用场景和必要性的，一成不变或一味遵循别人的标准不见得就一定是最佳的，至少我们要有探索的精神和专研的行动，结果各有评价，让实践来检验吧。一个粗浅的道理，无论网速再快，传输10个字节和传输1000个字节的时间和占用资源永远不会相等。