高并发经验

一，网站访问量和服务器宽带的关系
影响在线人数的因素，1）访问量；2）网站类型。如果是出文字的网站（如小说站），1M带宽带动日均5000IP，还勉强。如果是普通网站有图片，有文字、论坛、新闻资讯类型网站大概1M能带一千IP。考虑到高峰期并发，1M高峰期还会卡。
下面根据影响因素计算下1M带宽能同时承受多少人在线。（以网络状况良好为前提）

1、 打开网站8秒原则；

2、 评判的只是：用户从服务器下载文件的速度；

3、 页面的标准尺寸大小为：60KB。

参考公式：支持连接个人 = 服务器带宽/页面尺寸大小，通过计算大致结果是，1Mbps的带宽（服务器的1M带宽最快上下速度能达到1M/s），跟一般家用的带宽稍有区别，支持的连接数为：17个。因此，N M带宽可以支持的同时在线人数大概为N*17个。所以，1M带宽的服务器，日均3000IP以下应该没问题。当然如果网站每个页面都比较大的话，那就没这么多了。具体多少，可以按照上面的算法算下。
同时在线访问数由几个方面决定：

1、服务器的质量。

服务器分为高中低三种。不同型号品牌的服务器能够承受的流量是不同的，所以，这是影响同时在线访问数量的原因之一。

2、宽带的大小。

假若服务器保证的最大带宽是5M (即5Mbit/s)，相应服务器的数据最高传输速度应为5Mbit/s x 1024/8=640KB，1分钟流量大约640 x 60=38400KB。假设毎个用户1分钟内始终占用10KB的流量，即该1分钟内支持占用这样的流量的同时在线访问人数为3840人（视频类大流量网站不在此例）。

但是，并不能保证每个用户在1分钟内只有一次到该站的链接，假如每个用户在1分钟内有两次或以上到该站的链接（每个链接始终占用10KB的流量），那么支持在线人数应该在2000以下。

综上所述，一台中低端服务器通常支持在线人数最高为2000人左右，而且只适合普通网站建设后的服务器和文字型论坛，不包括图片类、下载类、视频类等。如果是其他类型的网站，那就要考虑更高配置的服务器以及更大的带宽。

二：负载均衡(服务器集群nginx配置)

nginx.png

https://blog.csdn.net/wang379275614/article/details/47778201
三：分布式锁
https://www.cnblogs.com/Leo_wl/p/7513314.html
关于分布式锁，有过javaEE开发经验的就会说了，系统为了应对高并发，会搭建一个比如tomcat集群，集群内服务都是访问的同一台数据库，有多台服务器同时修改同一条数据库数据的操作，但是我们并没有在服务器中使用分布式锁？按照上面对分布式锁的解释，两个不同系统上的JVM进程同时访问数据库的同一个资源，这个时候我们应该使用分布式锁进行控制。
　　这说的没有错，但是我们忘记了数据库的特性了。如果两台服务器仅仅是直接访问（通过url）并操作某台服务器硬盘中某个文件同一行数据，这个时候我们必须用分布式锁。但是因为这两台服务器访问的数据是存储在数据库中的（数据库本身就是一个服务程序，多线程的接收外部系统发来的请求），两台服务器的请求通过网络IO发送到数据库服务器后，然后把请求交给数据库服务的进程处理，数据库服务器是多线程接收请求并处理的，这个时候关于某表某一行数据的多线程访问控制是由数据库服务进行控制的（就是数据库服务的代码中进行了线程上的加锁处理），这就是数据库服务器的行锁等特性，因为数据库那一端已经对外部多个系统的请求进行了一个锁操作，所以不需要我们在应用服务端进行分布式锁的开发。　
　　那如果想同时更新数据库的多行数据，这个时候数据库的行锁就无法保证了。这个时候我们就要使用分布式锁，是的这个时候就可以使用，注意我用的是可以。为什么说可以呢？因为数据库本身就提供了这个机制，事务以及他的隔离级别。当然你也可以不用数据库提供的事务，用分布式锁。
四：缓存服务器redis
1、Redis在Java web中的应用
https://www.cnblogs.com/lin346112883/p/9832159.html
2、java web项目中Spring整合Redis的使用
https://blog.csdn.net/qq_25902435/article/details/79804952
五：数据库主从同步，读写分离，分库分表
https://blog.51cto.com/12227558/2104641
mycat 分表分库
六：数据库表优化
1，使用分析工具 进行慢查询分析
https://www.jianshu.com/p/ca0e48d83130
2，单机优化
https://blog.csdn.net/qq_38225558/article/details/87896026
七:Linux性能优化之CPU、内存、IO优化
https://blog.csdn.net/ZYC88888/article/details/79027944