server architecture
From the early stage of development to the gradual maturity of business, the server architecture also changes from relatively single to cluster, and then to distributed services.
A service that can support high concurrency requires a good server architecture, which requires balanced load, a master-slave cluster for databases, a master-slave cluster for nosql cache, and a CDN for static files.
The server architecture that needs to be roughly used is as follows:
- server
- Load balance (eg: nginx, Alibaba Cloud SLB)
- Resource monitoring
- distributed
- database
- Master-slave separation, clustering
- DBA table optimization, index optimization, etc.
- distributed
- NOSQL
- say again
- Master-slave separation, clustering
- mongodb
- Master-slave separation, clustering
- memcache
- Master-slave separation, clustering
- say again
- CDN
- html
- css
- js
- imag
Concurrency testing
Third Party Services:
- Alibaba Cloud Performance Test
- Apache JMeter
- Visual Studio Performance Load Test
- Microsoft Web Application Stress Tool
Practical plan
General solution
The daily user traffic is large, but it is relatively scattered, and occasionally there are high gatherings of users;
Scenario: User check-in, user center, user order, etc.
Server architecture diagram:
illustrate:
These services in the scenario are basically operated by users after entering the APP. Except for event days (618, Double 11, etc.), the number of users of these services will not be highly aggregated, and the tables related to these services are all big data tables. , the business is mostly query operations, so we need to reduce the query that users directly hit the DB; query the cache first, if the cache does not exist, then perform the DB query to cache the query results.
Updating user-related caches requires distributed storage. For example, using user IDs for hash grouping and distributing users to different caches, the total amount of such a cache collection will not be large and will not affect query efficiency.
Schemes such as:
- Users sign in to earn points
- Calculate the key distributed by users, find the user's check-in information today in redis hash
- If the check-in information is queried, return the check-in information
- If there is no query, the DB queries whether you have checked in today. If you have checked in, the check-in information will be synchronized to the redis cache.
- If today's check-in record is not queried in the DB, perform the check-in logic, operate the DB to add today's check-in record, and add check-in points (this entire DB operation is a transaction)
- Cache the check-in information to redis, and return the check-in information
注意这里会有并发情况下的逻辑问题，如：一天签到多次，发放多次积分给用户。
- 用户订单
- 这里我们只缓存用户第一页的订单信息，一页40条数据，用户一般也只会看第一页的订单数据
- 用户访问订单列表，如果是第一页读缓存，如果不是读DB
- 计算出用户分布的key,redis hash中查找用户订单信息
- 如果查询到用户订单信息，返回订单信息
- 如果不存在就进行DB查询第一页的订单数据，然后缓存redis，返回订单信息
- 用户中心
- 计算出用户分布的key,redis hash中查找用户订单信息
- 如果查询到用户信息，返回用户信息
- 如果不存在进行用户DB查询，然后缓存redis，返回用户信息
- 其他业务
- 上面例子多是针对用户存储缓存，如果是公用的缓存数据需要注意一些问题，如下
注意公用的缓存数据需要考虑并发下的可能会导致大量命中DB查询，可以使用管理后台更新缓存，或者DB查询的锁住操作。
以上例子是一个相对简单的高并发架构，并发量不是很高的情况可以很好的支撑，但是随着业务的壮大，用户并发量增加，我们的架构也会进行不断的优化和演变，比如对业务进行服务化，每个服务有自己的并发架构，自己的均衡服务器，分布式数据库，nosql主从集群，如：用户服务、订单服务；
消息队列
秒杀、秒抢等活动业务，用户在瞬间涌入产生高并发请求
场景：定时领取红包，等
服务器架构图：
说明：
场景中的定时领取是一个高并发的业务，像秒杀活动用户会在到点的时间涌入，DB瞬间就接受到一记暴击，hold不住就会宕机，然后影响整个业务；
像这种不是只有查询的操作并且会有高并发的插入或者更新数据的业务，前面提到的通用方案就无法支撑，并发的时候都是直接命中DB；
设计这块业务的时候就会使用消息队列的，可以将参与用户的信息添加到消息队列中，然后再写个多线程程序去消耗队列，给队列中的用户发放红包；
方案如：定时领取红包
- 一般习惯使用 redis的 list
- 当用户参与活动，将用户参与信息push到队列中
- 然后写个多线程程序去pop数据，进行发放红包的业务
- 这样可以支持高并发下的用户可以正常的参与活动，并且避免数据库服务器宕机的危险
附加：
通过消息队列可以做很多的服务。
如：定时短信发送服务，使用sset(sorted set)，发送时间戳作为排序依据，短信数据队列根据时间升序，然后写个程序定时循环去读取sset队列中的第一条，当前时间是否超过发送时间，如果超过就进行短信发送。
一级缓存
高并发请求连接缓存服务器超出服务器能够接收的请求连接量，部分用户出现建立连接超时无法读取到数据的问题；
因此需要有个方案当高并发时候时候可以减少命中缓存服务器；
这时候就出现了一级缓存的方案，一级缓存就是使用站点服务器缓存去存储数据，注意只存储部分请求量大的数据，并且缓存的数据量要控制，不能过分的使用站点服务器的内存而影响了站点应用程序的正常运行，一级缓存需要设置秒单位的过期时间，具体时间根据业务场景设定，目的是当有高并发请求的时候可以让数据的获取命中到一级缓存，而不用连接缓存NOSQL数据服务器，减少NOSQL数据服务器的压力
比如APP首屏商品数据接口，这些数据是公共的不会针对用户自定义，而且这些数据不会频繁的更新，像这种接口的请求量比较大就可以加入一级缓存；
服务器架构图：
合理的规范和使用nosql缓存数据库，根据业务拆分缓存数据库的集群，这样基本可以很好支持业务，一级缓存毕竟是使用站点服务器缓存所以还是要善用。
静态化数据
高并发请求数据不变化的情况下如果可以不请求自己的服务器获取数据那就可以减少服务器的资源压力。
对于更新频繁度不高，并且数据允许短时间内的延迟，可以通过数据静态化成JSON，XML,HTML等数据文件上传CDN，在拉取数据的时候优先到CDN拉取，如果没有获取到数据再从缓存，数据库中获取，当管理人员操作后台编辑数据再重新生成静态文件上传同步到CDN，这样在高并发的时候可以使数据的获取命中在CDN服务器上。
CDN节点同步有一定的延迟性，所以找一个靠谱的CDN服务器商也很重要.
其他方案
- For data that is not frequently updated, APP and PC browsers can cache the data locally, and then upload the version number of the current cached data each time the interface is requested. The server receives the version number to determine the version number and the latest data version number. Whether they are consistent, if they are different, query the latest data and return the latest data and the latest version number. If they are the same, return a status code to inform that the data is up-to-date.
减少服务器压力：资源、带宽
Transfer: https://blog.thankbabe.com/2016/09/14/high-concurrency-scheme/