1 秒杀场景

商品秒杀，抢红包，抽奖等

2 技术特点

读多写少，高并发，资源冲突（短时间内突发性高并发请求）

3 应对策略

读多写少

缓存：把热点数据丢到缓存中，浏览器缓存，本地缓存等
高并发

限流：延迟处理策略，拒绝访问
	
负载均衡：使用nginx实现反向代理和负载均衡
	
缓存：使用redis，memcache等，减轻服务器和数据库压力
	
异步：将同步的并发请求转移为异步，提高响应速度
	
队列：rabbitMQ，activeMQ等，实现应用解耦，工作队列减轻服务器压力，提高响应速度
资源冲突

    ● 数据库锁

            ● 乐观锁：版本号机制，CAS操作

            ● 悲观锁：行锁，表锁，读锁，写锁，select * from tb_xx for update

    ● 分布式锁

            ● reids的setnx指令

            ● redis的RedLock算法

            ● zookeeper有序节点

    ● 其他原子操作

           ● incr

           ● decr

4 应用架构及解决方案

 

一、场景：

1、有数据表：ConCurrency，

CREATE TABLE [dbo].[ConCurrency](
    [ID] [int] NOT NULL,
     [Total] [int] NULL
 )

2、初始值：ID=1,Total = 0

3、现要求每一次客户端请求Total + 1

二、单线程

         static void Main(string[] args)
         {
            ...
            new Thread(Run).Start();
             ...
        }
 
        public static void Run()
         {
             for (int i = 1; i <= 100; i++)
             {
                     var total = DbHelper.ExecuteScalar("Select Total from ConCurrency where Id = 1", null).ToString();
                     var value = int.Parse(total) + 1;

                    DbHelper.ExecuteNonQuery(string.Format("Update ConCurrency Set Total = {0} where Id = 1", value.ToString()), null);
                     Thread.Sleep(1);
            }
         }

2.1 按要求，正常情况下应该输出：100

2.2 运行结果



貌似没有问题。

三、多线程并发

3.1 Main改一下

         static void Main(string[] args)
         {
             ...
            new Thread(Run).Start();
            new Thread(Run).Start();
             ...
         }

3.2 我们预期应该是要输出200

3.3 运行结果



很遗憾，却是150，造成这个结果的原因是这样的：T1、T2获取Total（假设此时值为10），T1更新一次或多次后，T2才更新（Total:10）

这就造成之前T1提交的被覆盖了

3.4 如何避免呢？一般做法加锁就可以了，如Run改成如下

         public static void Run()
         {
             for (int i = 1; i <= 100; i++)
            {
                 lock (resource)
                 {
                     var total = DbHelper.ExecuteScalar("Select Total from ConCurrency where Id = 1", null).ToString();
                     var value = int.Parse(total) + 1;
 
                     DbHelper.ExecuteNonQuery(string.Format("Update ConCurrency Set Total = {0} where Id = 1", value.ToString()), null);
                 }
 
                 Thread.Sleep(1);
            }
         }

3.5 再次运行



四、用队列实现

4.1、定义队列

static ConcurrentQueue<int> queue = new ConcurrentQueue<int>();

         /// <summary>生产者</summary>
        public static void Produce()
         {
             for (int i = 1; i <= 100; i++)
             {
                 queue.Enqueue(i);
             }
         }
 
         /// <summary>消费者</summary>
         public static void Consume()
        {
             int times;
             while (queue.TryDequeue(out times))
             {
                 var total = DbHelper.ExecuteScalar("Select Total from ConCurrency where Id = 1", null).ToString();
                var value = int.Parse(total) + 1;
 
                 DbHelper.ExecuteNonQuery(string.Format("Update ConCurrency Set Total = {0} where Id = 1", value.ToString()), null);
                 Thread.Sleep(1);
             }
         }

4.2 Main改一下

         static void Main(string[] args)
         {
             ...
            new Thread(Produce).Start();
             new Thread(Produce).Start();
            Consume();
             ...
         }

4.3 预期输出200，看运行结果



4.4 集群环境下测试，2台机器





有问题！最后运行的那台机器居然是379，数据库也是379。

这超出了我们的预期结果，看来即便加锁，对于高并发场景也是不能解决所有问题的

五、分布式队列 

5.1 解决上边问题可以用分布式队列，这里用的是redis队列

         /// <summary>生产者</summary>
         public static void ProduceToRedis()
         {
             using (var client = RedisManager.GetClient())
             {
                 for (int i = 1; i <= 100; i++)
                {
                     client.EnqueueItemOnList("EnqueueName", i.ToString());
                 }
            }
         }
 
         /// <summary>消费者</summary>
         public static void ConsumeFromRedis()
         {
            using (var client = RedisManager.GetClient())
             {
                 while (client.GetListCount("EnqueueName") > 0)
                 {
                    if (client.SetValueIfNotExists("lock", "lock"))
                     {
                         var item = client.DequeueItemFromList("EnqueueName");
                         var total = DbHelper.ExecuteScalar("Select Total from ConCurrency where Id = 1", null).ToString();
                         var value = int.Parse(total) + 1;
 
                         DbHelper.ExecuteNonQuery(string.Format("Update ConCurrency Set Total = {0} where Id = 1", value.ToString()), null);
 
                         client.Remove("lock");
                     }

                     Thread.Sleep(5);
                 }
             }
         }

5.2 Main也要改改

         static void Main(string[] args)
         {
            ...
             new Thread(ProduceToRedis).Start();
             new Thread(ProduceToRedis).Start();
             Thread.Sleep(1000 * 10);
 
             ConsumeFromRedis();
             ...
         }

5.3 在集群里再试试，2个都是400，没有错（因为每个站点开了2个线程）





可以看到数据完全正确！

如今不管面试还是项目中都会听到高并发这个词，尽管我没主导设计过千万、亿万级的项目并从中经历高并发场景，但至少主导并经历百万级的高并发（QPS 过万）。
本场 Chat 首先会带领大家聊聊高并发。本场 Chat 您将学到如下内容：
了解共享出行业务痛点；
了解并发下数据处理；
了解高并发下的服务器设计；
了解高并发下的缓存层；
了解高并发下的数据层。
某共享汽车出行平台从随着业务的发展，可能大家听到出行以为是滴滴，然而不是，不过今年美团等巨头也入场共享汽车行业，表明公司业务至少是不错的，城市也在不断扩张，随着最初的 3 台车到目前运营几千台车，也在不断发展过程中，拥有了自己的固件平台，也正式由于此导致在一些业务过程中，由于系统访问量迅速膨胀，很多复杂的问题要在短时间内解决，且不能影响线上业务，这是对我乃至团队成员是一个不小的挑战，本文将会阐述共享汽车平台架构演变过程遇到的一些有代表性的问题和解决方案。
LBS 的瓶颈和解决手段
  
场景：用户下单后并且取车后，乃至还车车辆所有的行驶轨迹
  
车辆每隔几秒钟上报一次经纬度，存储在 mysql 里；
  
用户在首页根据当前定位，通过 mysql 数据推荐出最优的有车辆的网点；
  
将订单通过短信服务推送给用户；
  
用户到最近匹配网点取车，开始行程。
  
mysql 集群是一主多从的复制集方式，读写都很密集（1w+/s 写、2w+/s 读）时出现以下问题：
  
从服务器 CPU 负载急剧上升；
  
查询性能急剧降低（尤其随着车辆增长时，慢查询很多，导致还车接口极度慢）；
  
查询吞吐量大幅降低；
  
主从复制出现较大的延迟。
  
基于当时 mysql 的 sql、主从延迟问题，还有定时任务脚本凌晨大量的锁等待，需要技术团队去解决这些问题，然而对于 sql 大量的查询，可以做多从去解决，分担查询压力，提高查询速度；车辆轨迹的写入，考虑到 mysql 写入压力过大，会考虑把车辆轨迹写入到redis队列里，再设定一个业务低峰期时期，去同步 redis 数据到 mysql，毕竟 redis 内存有限，mysql 作为数据存储还是可以的（存储引擎 innodb 变更为 tokudb，基于高压缩比，数据写入），如此基本解决了主从延迟、sql 查询、db 写入压力。
长连接服务稳定性
我们的长连接服务通过 Socket 接收底层硬件上报车辆轨迹给服务端。尤其在公司 B 轮融资后，车辆迅速变多，长连接服务非常不稳定。
先说说硬件问题，现象是 CPU 的第一个核经常使用率 100%，其他的核却非常空闲，系统吞吐量上不去，对业务的影响很大。经过较长时间排查，最终发现这是因为服务器用了单队列网卡，I/O 中断都被分配到了一个 CPU 核上，大量数据包到来时，单个 CPU 核无法全部处理，导致 LVS 不断丢包连接中断。最后解决这个问题其实很简单，换成多队列网卡就行。
再看软件问题，长连接服务当时用 swoole 实现，使用 swoole 本身技术人员把控有限，也出现各种问题：正常 php 的终止是 exit，错用 swoole 终止、线程分配过少、内存分配过低、swoole跟底层硬件通信缺少监控。最后团队成员基于这些问题，在预发布环境，迅速去修复，也做了硬件的tcp负载，减少单台 swoole 的压力。
高并发业务案例
随着系统访问量迅速增大，日订单从几千到数十万，从分时套餐到包日、包天、包月，导致个人中心、优惠券兑换、用户订单这些平时量小时，没任何影响到各种慢等待、重复数据写入、穿透 redis、核心表主从延迟等。
1. 高并发带来的后果
服务端
导致站点服务器或 DB 服务器资源被占满崩溃，数据的存储和更新结果和理想的设计是不一样的，比如：出现重复的数据记录，多次添加了用户日志记录及充值送流水等。
用户
尼玛，这么卡，老子来参加活动的，刷新了还是这样，垃圾 app，体验太差，充值不了，无法使用订车，再也不来了！
经历
在做公司用户端 app 过程中，经常会有这样的需求，比如运营想做个充值送活动、优惠券兑换活动等，如果没有考虑高并发下的数据处理，那就 game over，很容易导致用户充值多送等各种超出正常业务的逻辑，更会导致大量错误数据，这就是设计产品需要考虑的问题。
由于面向用户，一个活动的损失直接带来的是金钱和用户的流失。不像传统企业 erp 系统、cms 系统，专门给内部员工用的。互联网产品，用户和资金流水是至关重要。
2. 并发下的数据处理
通过表设计添加唯一约束、数据处理逻辑，使用事务防止并发下的数据错乱问题，而 db 的唯一约束，程序层还需要处理 db 写入报错异常处理，否则在程序内循环可能导致程序中间终止；
通过服务端锁进程防止高并发下的错乱问题，这里主要讲述的是在并发请求下的数据逻辑处理接口，如何保证数据的一致性和完整性。这里的并发可能是大量用户导致的，也有可能是用工具模拟请求导致的。
  
案例1：通过表设计防止并发导致数据错乱
  
需求点：充值 1000 送 1000 活动，只能送一次
  
已有表：充值流水表，资金表
  
风险：在高并发下，会导致一个用户充值送会送多次优惠
设计
首先根据需求我会添加一张充值流水记录表，重点来了，这张表需要把用户唯一标识字段 (userid,chargeid,charge_type) 字段添加为唯一约束，或者唯一索引，这样就可以防止并发的时候插入重复用户的充值送流水记录。
然后再程序代码逻辑里，先执行真实资金充值数据的添加。这里可以防止并发，添加成功后再进行充值流水的添加，可以防止重复地添加充值送流水了。
最后我还是建议所有的数据操作都写在一个 sql 事务里面， 这样在添加失败时可以回滚数据。
  
案例 2：通过程序防止错乱数据
  
需求：缓存数据到 cache 里，当缓存不存在的时候，从数据库中获取并保存在 cache 里。如果存在从 cache 里获取，每天 10 点必须更新一次，其他时间点缓存两个小时更新一次到 10 点的时候，凡是打开页面的用户会自动刷新页面。
  
问题点：这里有个逻辑用户触发缓存的更新，用户刷新页面，当缓存存在的时候，会取到最后一次缓存更新时间。如果当前时间大于十点，并且最后缓存时间是 10 点前，则会从数据库中重新获取数据保存到 cache 中。  客户端页面会在 10 点时候用 js 发起页面的刷新，就是因为有这样的逻辑，导致 10 点的时候有很多并发请求同时过来，然后就会导致很多的 sql 查询操作。  理想的逻辑是，只有一个请求会去数据库获取，其他都是从缓存中获取数据。（因为这个 sql 查询很耗服务器性能，所以导致在 10 点的时候，突然间数据库服务器压力暴增）
解决方案
通过（锁）lock，在从数据读取到缓存的那段代码前面加上锁，这样在并发的情况下只会有一个请求是从数据库里获取数据，其他都是从缓存中获取。
3. 访问量大的统计接口
  
需求：用户行为数据统计接口，用来记录用户搜索网点次数，用户通过点击网点，或者链接，或者其他方式进入到网点详情的行为次数。
  
问题点：这接口是给移动端用的，尽管接口有使用签名，但是网点有几千个，用户有百万，高峰时期的点击量很大
分析
设想如果同时有 1W 个用户同时在线点击网点，而且网点还需要加载所有车辆，估算 100 台，这样就会有 100W 个请求过来，服务端需要把请求数据入库。在实际线上环境可能还会超过这个请求量，如果不经过进行高并发设计处理，服务器分分钟给跪了。
解决问题
我们使用缓存数据库 redis，把所有网点用 hash 方式存储，每一次那个用户的点击、属于那个时间段的，由于这些数据只是对运营推动产品有用，所以可以设计让缓存数据定时同步到 db（不繁忙时刻）。
这里还有个解决方案，后期准备考虑用 mongodb 文档性数据库，鉴于它的高性能存储及数据切片，可以快速扩张。
其实还可以用 mysql 的日志存储系统 tukodb（专业写入：官方称至少比 innodb 高 9 倍、高性能压缩：官方宣称 1:12、可以在线添加索引和字段，速度快）。
4. 高并发下的服务器压力均衡，合理站点设计、db 部署
服务地 nginx 做负载均衡，压力均摊到后端服务器
部署 mysql 主从架构，合理利用三级缓存架构（本地缓存、nginx 缓存、redis 缓存）
在高并发接口的设计中可以使用高性能语言 go（尝试接入一些业务，效果还不错）
图片服务器分离，静态文件走 CDN
数据库的优化查询，索引优化及设计，去 join
消息存储机制，将数据添加到信息队列中 (redis list)，然后再写工具去入库
基于上述问题及一些场景的解决手段，为了避免去年年底春节活动时期充值送活动的大流量涌入，光微信端首页就有接近百万的访问导致整个微信端业务瘫痪，开始基于上述一些服务化的架构设计。
因此在开年就开始服务化实施，根据业务系统设计拆分为个人中心服务、优惠券服务、充值送服务、活动服务、订单服务、资金服务、网点车辆服务、车辆轨迹服务、消息服务等，之所以开始实施服务化的架构设计，主要是便于单个小组维护特定的服务；分摊由于特定服务压力过大导致的整个系统可用性。
在笔者写此文时，服务化只完成了个人中心服务、资金服务，鉴于目前当前运行了一月的效果，也经历每周的活动，在当前不管服务层、缓存层、数据层架构设计下，至少不会让 mysql 连接数如去年般动不动超过 8000，也顺利撑住 QPS 过万的压力，大访问量下数据量大的接口响应时长为平均 3s，表小的业务接口平均时长为 1s内。
总结
笔者认为，其实高并发场景下的业务，出现的问题还是有蛮多问题是差不多的，比如超卖（充值多送）、业务卡顿（锁等待）、部分服务器压力大（负载均衡不合理导致，没有做到有效均摊压力），所以不管什么行业业务，可以先找到可以借鉴的成熟方案去试错，再在业务发展过程中，去形成自己公司业务的架构方案，毕竟技术方案是基于业务场景，光靠一篇文章也不可能写出高并发中出现的所有问题和解决方案，其实大多的文章更多是基于自己项目中经历过的场景，分享一些解决方案和思路，关于一些技术问题，可以私聊交流，笔者相当热爱交流和探讨。
本文首发于GitChat，未经授权不得转载，转载需与GitChat联系。
阅读全文: http://gitbook.cn/gitchat/activity/5ae27db296075b3e02e2a08d
您还可以下载 CSDN 旗下精品原创内容社区 GitChat App ，阅读更多 GitChat 专享技术内容哦。

什么是热点数据
设想如下场景：

1、有一条现金账号（大商户在mysql上的一条记录），同时有数十万人在往上面转账，账务数据是必须同步持久化的，这种情况下很难做到所有请求同步update这条记录。
2、大商户准备一笔钱给社交网络的大量用户发放红包，需要在高并发下对这条账户减钱成功，并不会减成负数。
以上场景是不能用缓存、简单的分库分表来实现的，因为是对指定的一条数据进行操作，且要求同步持久化，这种问题简单用下图来表示：





解决方案：
对于场景1，可以称之为加钱频繁账户，可以采用加钱时只做记录（单条请求持久化），然后一段时间后再合并总金额一起update到目标账户上去。



对于场景2，称为减钱频繁账户，每次请求都必须对余额进行更新，然后才能进行下次操作，要不然可能会扣成负数造成资损；这种情况下，可以采用分拆子账户的方式，将一条账户数据拆成100条数据（一条100万变成100条一万），减钱请求随机命中其中一条。当出现子账户有余额，但不足以扣减时，进行子账户合并。最终100条数据又会合并成一条数据。
系统设计思路：
加法频繁数据，我们需要高可用的缓存/分布式数据库，将加法请求记录，由计划任务进行求和并update到目标数据。



减法频繁数据，需要有一个数据扩容的功能（对单条数据进行水平扩展），自动/手动将一条大额记录拆分成n个子记录，还有一个合并子记录的功能。
功能实现：