先了解些并发的基本概念。

程序

​ 程序 是数据和指令的有序集合，本身无意义，就是一个静态的概念。
​ 进程 是执行程序的一个运行过程，操作系统的资源分配，是动态概念。
​ 线程 是程序执行过程中的确切操作的执行对象。

线程

• 启动一个程序就会启动一个进程（Process），

• 一个进程内包含1个到多个线程（Thread）（必有一个main线程，还可能有其他守护线程daemon）,

• main线程是主线程，程序的入口，用于执行整个程序。

• 一个线程内包含多个指令（线程是cpu的调度和执行单位），

• cpu是接受线程，处理指令的地方，

• 一个cpu一次只能处理一个线程任务，

• 线程需要获取cpu时间片才能被cpu处理，

• 时间片很短，windows下约为15ms，

---

并发&并行

参照物为cpu

并发 指单个cpu同时处理多个线程任务，cpu在反复切换任务线程，实际还是串行化的；

并行 指多个cpu同时处理多个线程任务，cpu可以同时处理不同的任务，异步处理；

---

并发条件

第一，是否有共享变量
第二，是否多线程环境
第三，是否多个线程更新共享变量

---

一句话：多个线程操作同一个对象；

---

多线程执行

全局变量引起的并发问题【高并发、多线程】

背景

最近采用RabbitMQ做核心系统 团车 缴费解耦功能，消费端应用采用了SpringBoot2.1+Redis+RabbitMQ+jdbctemplate+Oaracle架构。 此消费端应用以前 单车 缴费时未出现任何问题，从监听—>日志输出—>业务逻辑处理等一切正常。 线上业务高峰期时也没有任何问题。 但是团车缴费功能启用时，多个200笔数据同时消费时就出现了数据 篡改 情况。 问题不难，看了日志之后发现对并发处理的不够到位。

结合着之前redis高并发多线程总结，顺便对这里也进行记录，希望帮助大家总结经验
另外一篇文章链接： redis高并发导致读写变慢（redis多线程）

模拟重现demo(部分代码略)

@Bean
public class controllerA{
    private BillingMQServiceImpl billingMQServiceimpl;
    public A(){    
        log.info("监听到billing消息队列消息：");
        billingMQServiceimpl.process(new String(body,"utf-8"),redisDateType);
    }
}

public class BillingMQServiceImpl{
    private String bizNo = "";
    private String sendBillingJson = "";
    private String resultJson = "";
    @Autowired
    private InfoToBillFeignService infoToBillFeignService;
    
    public process(String body){
        // 1. 取业务号
        bizNo = this.parseBody(body);
        // 2. 业务逻辑处理
        resultJson = this.noticSys();    
    }

    public String parseBody(String body) throws Exception {
        sendBillingJson = body;

        try {
            BillingInfoDto billingInfo = JSON.parseObject(body, BillingInfoDto.class);
            bizNo = billingInfo.getBody().getHbReceivableInfo().get(0).getCplyno();
        } catch (Exception ex) {
            log.error(ex.getMessage());
            throw ex;
        }
        log.info("billing MQ customer parse bizNo : " + bizNo);
        return bizNo;
    }

    @Override
    public void noticSys() {
        long startTime = System.currentTimeMillis();
        try {
            log.info(bizNo.get() + "send car-bill-cust start！");
            infoToBillFeignService.postData(sendBillingJson);
            log.info(bizNo.get() + "send car-bill-cust sucess！ cost " + (System.currentTimeMillis() - startTime) + " ms.");
        } catch (Exception e) {
            log.error(bizNo.get() +  "send car-bill-cust faild, exception message : " + e.getMessage() + " ,cost " + (System.currentTimeMillis() - startTime) + " ms.");
            throw e;
        }
    }
}

代码问题分析

以上这段代码在访问量不构成并发时不会出现什么问题。 但在并发情况下如当一个请求还未完成，另一个请求已经开始执行的情况下就会出现问题：

• 第二个请求执行执行process()方法会将第一个请求的bizNo以及sendBillingJson变量篡改。
• 导致第一个请求的数据没有执行业务逻辑noticSys() 中的infoToBillFeignService.postData(sendBillingJson); 所以第一笔数据就无法缴费了。

小编这样写的目的是想要把各个环节的日志都输出到日志文件中，实现在日志平台（filebeat+kafka+Elk）进行数据监控。 为了详细跟踪每一笔数据的情况所以需要在每个环节都通过业务号bizNo进行标记。但又不想通过方法参数的方式来传递，进而设置成了全局变量。

出现这个问题的原因

由于系统采用SpringBoot框架，底层原理还是Springmvc其核心控制器DispatcherServlet默认为每个controller生成单一实例来处理所有用户请求，所以在这个单一实例的controller中，它的controllerA也是一个实例处理所有请求， 这样controllerA的成员变量就被所有请求共享。这样就会出现并发请求时变量内容被篡改的问题。那么出现这种问题如何解决呢？

• 第一种方式： 全局变量改为局部变量，通过方法参数来传递。
• 第二种方式： Jdk提供了 java.lang.ThreadLocal,它为多线程并发提供了新思路。

  当使用ThreadLocal维护变量时，ThreadLocal为每个使用该变量的线程提供独立的变量副本，所以每一个线程都可以独立地改变自己的副本，而不会影响其它线程所对应的副本。
  ThreadLocal并不是一个Thread，而是Thread的局部变量。

解决方案-ThreadLocal

那么在什么地方使用ThreadLocal呢？ 什么变量是请求公用的就将该变量托付给ThreadLocal来管理其线程副本， 所以我们在Service BillingMQServiceImpl中使用它。

java.lang.ThreadLocal,它为多线程并发提供了新思路。
当使用ThreadLocal维护变量时，ThreadLocal为每个使用该变量的线程提供独立的变量副本，所以每一个线程都可以独立地改变自己的副本，而不会影响其它线程所对应的副本。
ThreadLocal并不是一个Thread，而是Thread的局部变量。

TdLocal使用语法

初始化：ThreadLocal stringLocal = new ThreadLocal();
赋值：stringLocal.set(value)
取值：stringLocal.get();

public class BillingMQServiceImpl{
    private ThreadLocal<String> sendBillingJson = new ThreadLocal<String>();
    private ThreadLocal<String> bizNo = new ThreadLocal<>();
    private ThreadLocal<String> resultJson =  new ThreadLocal<>();
    @Autowired
    private InfoToBillFeignService infoToBillFeignService;
    
    public process(String body){
        // 1. 取业务号
        bizNo.set(this.parseBody(body)) ;
        // 2. 业务逻辑处理
        resultJson.set(this.noticSys());    
    }

    public String parseBody(String body) throws Exception {
        sendBillingJson.set(body);

        try {
            BillingInfoDto billingInfo = JSON.parseObject(body, BillingInfoDto.class);
            bizNo.set(billingInfo.getBody().getHbReceivableInfo().get(0).getCplyno());
        } catch (Exception ex) {
            log.error(ex.getMessage());
            throw ex;
        }
        log.info("billing MQ customer parse bizNo : " + bizNo.get());
        return bizNo.get();
    }

    @Override
    public void noticSys() {
        long startTime = System.currentTimeMillis();
        try {
            log.info(bizNo.get() + "send car-bill-cust start！");
            infoToBillFeignService.postData(sendBillingJson.get());
            log.info(bizNo.get() + "send car-bill-cust sucess！ cost " + (System.currentTimeMillis() - startTime) + " ms.");
        } catch (Exception e) {
            log.error(bizNo.get() +  "send car-bill-cust faild, exception message : " + e.getMessage() + " ,cost " + (System.currentTimeMillis() - startTime) + " ms.");
            throw e;
        }
    }
}

模拟验证

此类并发篡改数据的问题，可以在开发工具中设置断点调试的方式来模拟并发。即第一次请求运行到断点时，查看bizNo, sendBillingJson内容，并且不让程序继续往下运行，同时再发起一个请求，再查看bizNo, sendBillingJson内容。 如内容是第一次请求的内容，并且让第一个请求跑完后，第二个请求到断线处的content正确时，可以确定不会出现并发问题。

转载网上资源链接

一、什么是高并发

高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。

 

高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发用户数等。

 

响应时间：系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms，这个200ms就是系统的响应时间。

吞吐量：单位时间内处理的请求数量。

QPS：每秒响应请求数。在互联网领域，这个指标和吞吐量区分的没有这么明显。

并发用户数：同时承载正常使用系统功能的用户数量。例如一个即时通讯系统，同时在线量一定程度上代表了系统的并发用户数。

 

二、如何提升系统的并发能力

互联网分布式架构设计，提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。

垂直扩展：提升单机处理能力。垂直扩展的方式又有两种：

（1）增强单机硬件性能，例如：增加CPU核数如32核，升级更好的网卡如万兆，升级更好的硬盘如SSD，扩充硬盘容量如2T，扩充系统内存如128G；

（2）提升单机架构性能，例如：使用Cache来减少IO次数，使用异步来增加单服务吞吐量，使用无锁数据结构来减少响应时间；

 

在互联网业务发展非常迅猛的早期，如果预算不是问题，强烈建议使用“增强单机硬件性能”的方式提升系统并发能力，因为这个阶段，公司的战略往往是发展业务抢时间，而“增强单机硬件性能”往往是最快的方法。

 

不管是提升单机硬件性能，还是提升单机架构性能，都有一个致命的不足：单机性能总是有极限的。所以互联网分布式架构设计高并发终极解决方案还是水平扩展。

 

水平扩展：只要增加服务器数量，就能线性扩充系统性能。水平扩展对系统架构设计是有要求的，如何在架构各层进行可水平扩展的设计，以及互联网公司架构各层常见的水平扩展实践，是本文重点讨论的内容。

 

三、常见的互联网分层架构

常见互联网分布式架构如上，分为：

（1）客户端层：典型调用方是浏览器browser或者手机应用APP

（2）反向代理层：系统入口，反向代理

（3）站点应用层：实现核心应用逻辑，返回html或者json

（4）服务层：如果实现了服务化，就有这一层

（5）数据-缓存层：缓存加速访问存储

（6）数据-数据库层：数据库固化数据存储

整个系统各层次的水平扩展，又分别是如何实施的呢？

 

四、分层水平扩展架构实践

反向代理层的水平扩展

反向代理层的水平扩展，是通过“DNS轮询”实现的：dns-server对于一个域名配置了多个解析ip，每次DNS解析请求来访问dns-server，会轮询返回这些ip。

当nginx成为瓶颈的时候，只要增加服务器数量，新增nginx服务的部署，增加一个外网ip，就能扩展反向代理层的性能，做到理论上的无限高并发。

 

站点层的水平扩展

站点层的水平扩展，是通过“nginx”实现的。通过修改nginx.conf，可以设置多个web后端。

当web后端成为瓶颈的时候，只要增加服务器数量，新增web服务的部署，在nginx配置中配置上新的web后端，就能扩展站点层的性能，做到理论上的无限高并发。

 

服务层的水平扩展

服务层的水平扩展，是通过“服务连接池”实现的。

站点层通过RPC-client调用下游的服务层RPC-server时，RPC-client中的连接池会建立与下游服务多个连接，当服务成为瓶颈的时候，只要增加服务器数量，新增服务部署，在RPC-client处建立新的下游服务连接，就能扩展服务层性能，做到理论上的无限高并发。如果需要优雅的进行服务层自动扩容，这里可能需要配置中心里服务自动发现功能的支持。

 

数据层的水平扩展

在数据量很大的情况下，数据层（缓存，数据库）涉及数据的水平扩展，将原本存储在一台服务器上的数据（缓存，数据库）水平拆分到不同服务器上去，以达到扩充系统性能的目的。

 

互联网数据层常见的水平拆分方式有这么几种，以数据库为例：

按照范围水平拆分

每一个数据服务，存储一定范围的数据，上图为例：

user0库，存储uid范围1-1kw

user1库，存储uid范围1kw-2kw

这个方案的好处是：

（1）规则简单，service只需判断一下uid范围就能路由到对应的存储服务；

（2）数据均衡性较好；

（3）比较容易扩展，可以随时加一个uid[2kw,3kw]的数据服务；

不足是：

（1）      请求的负载不一定均衡，一般来说，新注册的用户会比老用户更活跃，大range的服务请求压力会更大；

 

按照哈希水平拆分

每一个数据库，存储某个key值hash后的部分数据，上图为例：

user0库，存储偶数uid数据

user1库，存储奇数uid数据

这个方案的好处是：

（1）规则简单，service只需对uid进行hash能路由到对应的存储服务；

（2）数据均衡性较好；

（3）请求均匀性较好；

不足是：

（1）不容易扩展，扩展一个数据服务，hash方法改变时候，可能需要进行数据迁移；

 

这里需要注意的是，通过水平拆分来扩充系统性能，与主从同步读写分离来扩充数据库性能的方式有本质的不同。

通过水平拆分扩展数据库性能：

（1）每个服务器上存储的数据量是总量的1/n，所以单机的性能也会有提升；

（2）n个服务器上的数据没有交集，那个服务器上数据的并集是数据的全集；

（3）数据水平拆分到了n个服务器上，理论上读性能扩充了n倍，写性能也扩充了n倍（其实远不止n倍，因为单机的数据量变为了原来的1/n）；

通过主从同步读写分离扩展数据库性能：

（1）每个服务器上存储的数据量是和总量相同；

（2）n个服务器上的数据都一样，都是全集；

（3）理论上读性能扩充了n倍，写仍然是单点，写性能不变；

 

缓存层的水平拆分和数据库层的水平拆分类似，也是以范围拆分和哈希拆分的方式居多，就不再展开。

 

五、总结

高并发（High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。

提高系统并发能力的方式，方法论上主要有两种：垂直扩展（Scale Up）与水平扩展（Scale Out）。前者垂直扩展可以通过提升单机硬件性能，或者提升单机架构性能，来提高并发性，但单机性能总是有极限的，互联网分布式架构设计高并发终极解决方案还是后者：水平扩展。

互联网分层架构中，各层次水平扩展的实践又有所不同：

（1）反向代理层可以通过“DNS轮询”的方式来进行水平扩展；

（2）站点层可以通过nginx来进行水平扩展；

（3）服务层可以通过服务连接池来进行水平扩展；

（4）数据库可以按照数据范围，或者数据哈希的方式来进行水平扩展；

各层实施水平扩展后，能够通过增加服务器数量的方式来提升系统的性能，做到理论上的性能无限。

 

末了，希望文章的思路是清晰的，希望大家对高并发的概念和实践有个系统的认识，结合上一篇《究竟啥才是互联网架构“高可用”》的分享互联网分布式架构是不是逐步的不再神秘啦？