2024年高并发网站建设 篇1
很高兴能够回答你的问题。
要建设出高质量的H5响应式网站，小编觉得要注意一下几个细节。1.首先要确定网站的主题
网站建设之前要对网站进行全面的规划，通过网站主题我们可以让用户了解我们，并且可以准确的找到自己想找的内容。从网站运营的角度出发，网站主题明确，那么内容就可以很好的把握。
2.导航框架
小企业网站总体内容少，应该尽可能的时网站信息扁平化，只设置头部导航条（不要设置边栏导航），栏目层次最多两层，各个产品的类型、型号等容易检索，到达没有一个产品页面的层次更少、点击数更少。这样，一方面既有利于搜索引擎抓取的方便，也有利于客户在网站中操作更清晰便捷。
3.网站里面的内容
网站的内容要和网站的主题还有我们要做的关键词相关，并且要有一定的可读性和实用性，让用户可以从中学到知识，学到方法。
4.网站页面
尽可能的精心制作每一个页面的内容，内容结构层次清晰，切换顺利，页面内图文并茂，图片处理得当。页面干净整洁，体面大方。
除了以上几点，还要注意网站细节上的设计，如何让用户使用起来更加方便，查找东西流畅，这都是要考虑的。
小编就提出以上几点，希望可以帮助你。
立即点击上方关注“小奕日记”头条号，了解更多你不知道的干货吧！
2024年高并发网站建设 篇2
许多人一上来就高并发架构，我觉的应该先谈业务，谈业务的频率，业务的分布，采用什么样的业务模式，客户的分布，客户应用模式，销售模式，或者变现的点，还有网站的交互模式，交流的程度等等。
然后聊硬件的投资，主机资源多少，网络资源多少，或者云平台多少，多少cpu，多少内存，多少存储，是否有异地，是否CDN等等。
然后考虑业务交互的数据，目标响应速度，负载的预估，最高多少，性能多少，在这一系列的前提下，再说高并发架构。
现在高并发架构基本已经不是什么秘密，比如负载均衡，缓存，异步处理，并行架构，水平扩展，纵向扩展等等
一般分层包括客户端（UI）用户反向代理，应用层，服务层，缓存，数据库，每个层级按照上述的数据进行规划。
最后要对各个环节进行压测，确认达到相关指标数据。
相关的资料也很多，比如大型网站技术架构：核心原理与案例分析
虽然是一本老书了，但是还是具有指导意义的
2024年高并发网站建设 篇3
本文分享自华为云社区《
【高并发】高并发场景下如何优化服务器的性能？-云社区-华为云》，作者： 冰 河 。写在前面
最近，有小伙伴在群里提问：Linux系统怎么设置tcp_nodelay参数？也有小伙伴说问我。那今天，我们就来根据这个问题来聊聊在高并发场景下如何优化服务器的性能这个话题。
其实，tcp_nodelay参数并不是在操作系统级别进行配置的，而是在TCP套接字上添加tcp_nodelay参数来关闭粘包算法，以便使数据包能够立即投递出去。tcp_nodelay参数主要是对TCP套接字来说的，那对于服务器硬件，如果要使其能够支撑上百万甚至上千万的并发，我们该如何对其进行优化呢？操作系统
这里，我使用的操作系统为CentOS 8，我们可以输入如下命令来查看操作系统的版本。
对于高并发的场景，我们主要还是优化操作系统的网络性能，而操作系统中，有很多关于网络协议的参数，我们对于服务器网络性能的优化，主要是对这些系统参数进行调优，以达到提升我们应用访问性能的目的。系统参数
在CentOS 操作系统中，我们可以通过如下命令来查看所有的系统参数。
部分输出结果如下所示。
这里的参数太多了，大概有一千多个，在高并发场景下，我们不可能对操作系统的所有参数进行调优。我们更多的是关注与网络相关的参数。如果想获得与网络相关的参数，那么，我们首先需要获取操作系统参数的类型，如下命令可以获取操作系统参数的类型。
运行命令输出的结果信息如下所示。
其中的net类型就是我们要关注的与网络相关的操作系统参数。我们可以获取net类型下的子类型，如下所示。
输出的结果信息如下所示。
在Linux操作系统中，这些与网络相关的参数都可以在/etc/sysctl.conf 文件里修改，如果/etc/sysctl.conf 文件中不存在这些参数，我们可以自行在/etc/sysctl.conf 文件中添加这些参数。
在net类型的子类型中，我们需要重点关注的子类型有：core和ipv4。优化套接字缓冲区
如果服务器的网络套接字缓冲区太小，就会导致应用程序读写多次才能将数据处理完，这会大大影响我们程序的性能。如果网络套接字缓冲区设置的足够大，从一定程度上能够提升我们程序的性能。
我们可以在服务器的命令行输入如下命令，来获取有关服务器套接字缓冲区的信息。
输出的结果信息如下所示。
其中，带有max、default、min关键字的为分别代表：最大值、默认值和最小值；带有mem、rmem、wmem关键字的分别为：总内存、接收缓冲区内存、发送缓冲区内存。
这里需要注意的是：带有rmem 和 wmem关键字的单位都是“字节”，而带有mem关键字的单位是“页”。“页”是操作系统管理内存的最小单位，在 Linux 系统里，默认一页是 4KB 大小。如何优化频繁收发大文件
如果在高并发场景下，需要频繁的收发大文件，我们该如何优化服务器的性能呢？
这里，我们可以修改的系统参数如下所示。
这里，我们做个假设，假设系统最大可以给TCP分配 2GB 内存，最小值为 256MB，压力值为 1.5GB。按照一页为 4KB 来计算， tcp_mem 的最小值、压力值、最大值分别是 65536、393216、524288，单位是“页” 。
假如平均每个文件数据包为 512KB，每个套接字读写缓冲区最小可以各容纳 2 个数据包，默认可以各容纳 4 个数据包，最大可以各容纳 10 个数据包，那我们可以算出 tcp_rmem 和 tcp_wmem 的最小值、默认值、最大值分别是 1048576、2097152、5242880，单位是“字节”。而 rmem_default 和 wmem_default 是 2097152，rmem_max 和 wmem_max 是 5242880。
注：后面详细介绍这些数值是如何计算的~~
这里，还需要注意的是：缓冲区超过了 65535，还需要将net.ipv4.tcp_window_scaling 参数设置为 1。
经过上面的分析后，我们最终得出的系统调优参数如下所示。
优化TCP连接
对计算机网络有一定了解的小伙伴都知道，TCP的连接需要经过“三次握手”和“四次挥手”的，还要经过慢启动、滑动窗口、粘包算法等支持可靠性传输的一系列技术支持。虽然，这些能够保证TCP协议的可靠性，但有时这会影响我们程序的性能。
那么，在高并发场景下，我们该如何优化TCP连接呢？
（1）关闭粘包算法
如果用户对于请求的耗时很敏感，我们就需要在TCP套接字上添加tcp_nodelay参数来关闭粘包算法，以便数据包能够立刻发送出去。此时，我们也可以设置net.ipv4.tcp_syncookies的参数值为1。
（2）避免频繁的创建和回收连接资源
网络连接的创建和回收是非常消耗性能的，我们可以通过关闭空闲的连接、重复利用已经分配的连接资源来优化服务器的性能。重复利用已经分配的连接资源大家其实并不陌生，像：线程池、数据库连接池就是复用了线程和数据库连接。
我们可以通过如下参数来关闭服务器的空闲连接和复用已分配的连接资源。
（3）避免重复发送数据包
TCP支持超时重传机制。如果发送方将数据包已经发送给接收方，但发送方并未收到反馈，此时，如果达到设置的时间间隔，就会触发TCP的超时重传机制。为了避免发送成功的数据包再次发送，我们需要将服务器的net.ipv4.tcp_sack参数设置为1。
（4）增大服务器文件描述符数量
在Linux操作系统中，一个网络连接也会占用一个文件描述符，连接越多，占用的文件描述符也就越多。如果文件描述符设置的比较小，也会影响我们服务器的性能。此时，我们就需要增大服务器文件描述符的数量。
例如：fs.file-max = 10240000，表示服务器最多可以打开10240000个文件。
关注#华为云开发者联盟#，第一时间了解华为云新鲜技术~
2024年高并发网站建设 篇4
首先回顾一下，整个架构右侧部分演进到的那个程度，其实已经非常的不错了，因为百亿流量，每秒十万级并发写入的场景，使用MQ限流削峰、分布式KV集群给抗住了。
接着使用了计算与存储分离的架构，各个Slave计算节点会负责提取数据到内存中，基于自研的SQL内存计算引擎完成计算。同时采用了数据动静分离的架构，静态数据全部缓存，动态数据自动提取，保证了尽可能把网络请求开销降低到最低。
另外，通过自研的分布式系统架构，包括数据分片和计算任务分布式执行、弹性资源调度、分布式高容错机制、主备自动切换机制，都能保证整套系统的任意按需扩容，高性能、高可用的的运行。
下一步，咱们得来研究研究架构里左侧的部分了。
二、日益膨胀的离线计算结果
其实大家会注意到，在左侧还有一个MySQL，那个MySQL就是用来承载实时计算结果和离线计算结果放在里面汇总的。
终端的商家用户就可以随意的查询MySQL里的数据分析结果，支撑自己的决策，他可以看当天的数据分析报告，也可以看历史上任何一段时期内的数据分析报告。
但是那个MySQL在早期可能还好一些，因为其实存放在这个MySQL里的数据量相对要小一些，毕竟是计算后的一些结果罢了。但是到了中后期，这个MySQL可是也岌岌可危了。
给大家举一个例子，离线计算链路里，如果每天增量数据是1000万，那么每天计算完以后的结果大概只有50万，每天50万新增数据放入MySQL，其实还是可以接受的。
但是如果每天增量数据是10亿，那么每天计算完以后的结果大致会是千万级，你可以算他是计算结果有5000万条数据吧，每天5000万增量数据写入左侧的MySQL中，你觉得是啥感觉？
可以给大家说说系统当时的情况，基本上就是，单台MySQL服务器的磁盘存储空间很快就要接近满掉，而且单表数据量都是几亿、甚至十亿的级别。
这种量级的单表数据量，你觉得用户查询数据分析报告的时候，体验能好么？基本当时一次查询都是几秒钟的级别。很慢。
更有甚者，出现过用户一次查询要十秒的级别，甚至几十秒，上分钟的级别。很崩溃，用户体验很差，远远达不到付费产品的级别。
所以解决了右侧的存储和计算的问题之后，左侧的查询的问题也迫在眉睫。新一轮的重构，势在必行！
三、分库分表 + 读写分离
首先就是老一套，分库分表 + 读写分离，这个基本是基于MySQL的架构中，必经之路了，毕竟实施起来难度不是特别的高，而且速度较快，效果比较显著。
整个的思路和之前第一篇文章（《大型系统架构演进之如何支撑百亿级数据的存储与计算》）讲的基本一致。
说白了，就是分库后，每台主库可以承载部分写入压力，单库的写并发会降低；其次就是单个主库的磁盘空间可以降低负载的数据量，不至于很快就满了；
而分表之后，单个数据表的数据量可以降低到百万级别，这个是支撑海量数据以及保证高性能的最佳实践，基本两三百万的单表数据量级还是合理的。
然后读写分离之后，就可以将单库的读写负载压力分离到主库和从库多台机器上去，主库就承载写负载，从库就承载读负载，这样避免单库所在机器的读写负载过高，导致CPU负载、IO负载、网络负载过高，最后搞得数据库机器宕机。
首先这么重构一下数据库层面的架构之后，效果就好的多了。因为单表数据量降低了，那么用户查询的性能得到很大的提升，基本可以达到1秒以内的效果。
四、每秒10万查询的高并发挑战
上面那套初步的分库分表+读写分离的架构确实支撑了一段时间，但是慢慢的那套架构又暴露出来了弊端出来了，因为商家用户都是开了数据分析页面之后，页面上有js脚本会每隔几秒钟就发送一次请求到后端来加载最新的数据分析结果。
此时就有一个问题了，渐渐的查询MySQL的压力越来越大，基本上可预见的范围是朝着每秒10级别去走。
但是我们分析了一下，其实99%的查询，都是页面JS脚本自动发出刷新当日数据的查询。只有1%的查询是针对昨天以前的历史数据，用户手动指定查询范围后来查询的。
但是现在的这个架构之下，我们是把当日实时数据计算结果（代表了热数据）和历史离线计算结果（代表了冷数据）都放在一起的，所以大家可以想象一下，热数据和冷数据放在一起，然后对热数据的高并发查询占到了99%，那这样的架构还合理吗？
当然不合理，我们需要再次重构系统架构。
五、 数据的冷热分离架构
针对上述提到的问题，很明显要做的一个架构重构就是冷热数据分离。也就是说，将今日实时计算出来的热数据放在一个MySQL集群里，将离线计算出来的冷数据放在另外一个MySQL集群里。
然后开发一个数据查询平台，封装底层的多个MySQL集群，根据查询条件动态路由到热数据存储或者是冷数据存储。
通过这个步骤的重构，我们就可以有效的将热数据存储中单表的数据量降低到更少更少，有的单表数据量可能就几十万，因为将离线计算的大量数据结果从表里剥离出去了，放到另外一个集群里去。此时大家可想而知，效果当然是更好了。
因为热数据的单表数据量减少了很多，当时的一个最明显的效果，就是用户99%的查询都是针对热数据存储发起的，性能从原来的1秒左右降低到了200毫秒以内，用户体验提升，大家感觉更好了。
六、自研Elasticsearch+HBase+纯内存的查询引擎
架构演进到这里，看起来好像还不错，但是其实问题还是很多。因为到了这个阶段，系统遇到了另外一个较为严重的问题：冷数据存储，如果完全用MySQL来承载是很不靠谱的。冷数据的数据量是日增长不断增加，而且增速很快，每天都新增几千万。
因此你的MySQL服务器将会面临不断的需要扩容的问题，而且如果为了支撑这1%的冷数据查询请求，不断的扩容增加高配置的MySQL服务器，大家觉得靠谱么？
肯定是不合适的！
要知道，大量分库分表后，MySQL大量的库和表维护起来是相当麻烦的，修改个字段？加个索引？这都是一场麻烦事儿。
此外，因为对冷数据的查询，一般都是针对大量数据的查询，比如用户会选择过去几个月，甚至一年的数据进行分析查询，此时如果纯用MySQL还是挺灾难性的。
因为当时明显发现，针对海量数据场景下，一下子查询分析几个月或者几年的数据，性能是极差的，还是很容易搞成几秒甚至几十秒才出结果。
因此针对这个冷数据的存储和查询的问题，我们最终选择了自研一套基于NoSQL来存储，然后基于NoSQL+内存的SQL计算引擎。
具体来说，我们会将冷数据全部采用ES+HBase来进行存储，ES中主要存放要对冷数据进行筛选的各种条件索引，比如日期以及各种维度的数据，然后HBase中会存放全量的数据字段。
因为ES和HBase的原生SQL支持都不太好，因此我们直接自研了另外一套SQL引擎，专门支持这种特定的场景，就是基本没有多表关联，就是对单个数据集进行查询和分析，然后支持NoSQL存储+内存计算。
这里有一个先决条件，就是如果要做到对冷数据全部是单表类的数据集查询，必须要在冷数据进入NoSQL存储的时候，全部基于ES和HBase的特性做到多表入库关联，进数据存储就全部做成大宽表的状态，将数据关联全部上推到入库时完成，而不是在查询时进行。
对冷数据的查询，我们自研的SQL引擎首先会根据各种where条件先走ES的分布式高性能索引查询，ES可以针对海量数据高性能的检索出来需要的那部分数据，这个过程用ES做是最合适的。
接着就是将检索出来的数据对应的完整的各个数据字段，从HBase里提取出来，拼接成完成的数据。
然后就是将这份数据集放在内存里，进行复杂的函数计算、分组聚合以及排序等操作。
上述操作，全部基于自研的针对这个场景的查询引擎完成，底层基于Elasticsearch、HBase、纯内存来实现。
七、实时数据存储引入缓存集群
好了，到此为止，冷数据的海量数据存储、高性能查询的问题，就解决了。接着回过头来看看当日实时数据的查询，其实实时数据的每日计算结果不会太多，而且写入并发不会特别特别的高，每秒上万也就差不多了。
因此这个背景下，就是用MySQL分库分表来支撑数据的写入、存储和查询，都没问题。
但是有一个小问题，就是说每个商家的实时数据其实不是频繁的变更的，在一段时间内，可能压根儿没变化，因此不需要高并发请求，每秒10万级别的全部落地到数据库层面吧？要全都落地到数据库层面，那可能要给每个主库挂载很多从库来支撑高并发读。
因此这里我们引入了一个缓存集群，实时数据每次更新后写入的时候，都是写数据库集群同时还写缓存集群的，是双写的方式。
然后查询的时候是优先从缓存集群来走，此时基本上90%以上的高并发查询都走缓存集群了，然后只有10%的查询会落地到数据库集群。
八、阶段性总结
好了，到此为止，这个架构基本左边也都重构完毕：热数据基于缓存集群+数据库集群来承载高并发的每秒十万级别的查询冷数据基于ES+HBase+内存计算的自研查询引擎来支撑海量数据存储以及高性能查询。
经实践，整个效果非常的好。用户对热数据的查询基本多是几十毫秒的响应速度，对冷数据的查询基本都是200毫秒以内的响应速度。
九、下一阶段的展望
其实架构演进到这里已经很不容易了，因为看似这么一张图，里面涉及到无数的细节和技术方案的落地，需要一个团队耗费至少1年的时间才能做到这个程度。
但是接下来，我们要面对的，就是高可用的问题，因为付费级的产品，我们必须要保证超高的可用性，99.99%的可用性，甚至是99.999%的可用性。
但是越是复杂的系统，越容易出现问题，对应的高可用架构就越是复杂无比