Golang 中的并发限制与超时控制

发表于 2021-03-11 | 分类于 Golang

做 Golang 并发的时候要对并发进行限制，对 goroutine 的执行要有超时控制。

并发

我们先来跑一个简单的并发看看

package main

import (
	"fmt"
	"time"
)

func run(task_id, sleeptime int, ch chan string) {
	time.Sleep(time.Duration(sleeptime) * time.Second)
	ch <- fmt.Sprintf("task id %d , sleep %d second", task_id, sleeptime)
	return
}

func main() {
	input := []int{3, 2, 1}
	ch := make(chan string)
	startTime := time.Now()
	fmt.Println("Multirun start")
	for i, sleeptime := range input {
		go run(i, sleeptime, ch)
	}
	for range input {
		fmt.Println(<-ch)
	}
	endTime := time.Now()
	fmt.Printf("Multissh finished. Process time %s. Number of tasks is %d", endTime.Sub(startTime), len(input))
}

函数 run() 接受输入的参数，sleep 若干秒。然后通过 go 关键字并发执行，通过 channel 返回结果。

channel 顾名思义，他就是 goroutine 之间通信的“管道”。管道中的数据流通，实际上是 goroutine 之间的一种内存共享。我们通过他可以在 goroutine 之间交互数据。

1 2	ch <- xxx // 向 channel 写入数据 <- ch // 从 channel 中读取数据

channel 分为无缓冲(unbuffered)和缓冲(buffered)两种。例如刚才我们通过如下方式创建了一个无缓冲的 channel。

1	ch := make(chan string)

channel 的缓冲，我们一会再说，先看看刚才看看执行的结果。

Multirun start
task id 2 , sleep 1 second
task id 1 , sleep 2 second
task id 0 , sleep 3 second
Multissh finished. Process time 3s. Number of tasks is 3
Program exited.

三个 goroutine `分别 sleep 了 3，2，1秒。但总耗时只有 3 秒。所以并发生效了，go 的并发就是这么简单。

按序返回

刚才的示例中，我执行任务的顺序是 0，1，2。但是从 channel 中返回的顺序却是 2，1，0。这很好理解，因为 task 2 执行的最快嘛，所以先返回了进入了 channel，task 1 次之，task 0 最慢。

如果我们希望按照任务执行的顺序依次返回数据呢？可以通过一个 channel 数组（好吧，应该叫切片）来做，比如这样

package main

import (
	"fmt"
	"time"
)

func run(task_id, sleeptime int, ch chan string) {
	time.Sleep(time.Duration(sleeptime) * time.Second)
	ch <- fmt.Sprintf("task id %d , sleep %d second", task_id, sleeptime)
	return
}

func main() {
	input := []int{3, 2, 1}
	chs := make([]chan string, len(input))
	startTime := time.Now()
	fmt.Println("Multirun start")
	for i, sleeptime := range input {
		chs[i] = make(chan string)
		go run(i, sleeptime, chs[i])
	}
	for _, ch := range chs {
		fmt.Println(<-ch)
	}
	endTime := time.Now()
	fmt.Printf("Multissh finished. Process time %s. Number of tasks is %d", endTime.Sub(startTime), len(input))
}

运行结果，现在输出的次序和输入的次序一致了。

Multirun start
task id 0 , sleep 3 second
task id 1 , sleep 2 second
task id 2 , sleep 1 second
Multissh finished. Process time 3s. Number of tasks is 3
Program exited.

阅读全文 »

支付宝的架构到底有多牛逼

发表于 2020-03-01 | 分类于系统架构

自 2008 年双 11 以来，在每年双 11 超大规模流量的冲击上，蚂蚁金服都会不断突破现有技术的极限。2010 年双 11 的支付峰值为 2 万笔/分钟，到 2017 年双 11 时这个数字变为了 25.6 万笔/秒。

2018 年双 11 的支付峰值为 48 万笔/秒，2019 年双 11 支付峰值为 54.4 万笔/秒，创下新纪录，是 2009 年第一次双 11 的 1360 倍。

在如此之大的支付 TPS 背后除了削峰等锦上添花的应用级优化，最解渴最实质的招数当数基于分库分表的单元化了，蚂蚁技术称之为 LDC（逻辑数据中心）。

本文不打算讨论具体到代码级的分析，而是尝试用最简单的描述来说明其中最大快人心的原理。

我想关心分布式系统设计的人都曾被下面这些问题所困扰过：

支付宝海量支付背后最解渴的设计是啥？换句话说，实现支付宝高 TPS 的最关键的设计是啥？
LDC 是啥？LDC 怎么实现异地多活和异地灾备的？
CAP 魔咒到底是啥？P 到底怎么理解？
什么是脑裂？跟 CAP 又是啥关系？
什么是 PAXOS，它解决了啥问题？
PAXOS 和 CAP 啥关系？PAXOS 可以逃脱 CAP 魔咒么？
Oceanbase 能逃脱 CAP 魔咒么？

如果你对这些感兴趣，不妨看一场赤裸裸的论述，拒绝使用晦涩难懂的词汇，直面最本质的逻辑。

LDC 和单元化

LDC（logic data center）是相对于传统的（Internet Data Center-IDC）提出的，逻辑数据中心所表达的中心思想是无论物理结构如何的分布，整个数据中心在逻辑上是协同和统一的。

这句话暗含的是强大的体系设计，分布式系统的挑战就在于整体协同工作（可用性，分区容忍性）和统一（一致性）。

单元化是大型互联网系统的必然选择趋势，举个最最通俗的例子来说明单元化。

我们总是说 TPS 很难提升，确实任何一家互联网公司（比如淘宝、携程、新浪）它的交易 TPS 顶多以十万计量（平均水平），很难往上串了。

因为数据库存储层瓶颈的存在再多水平扩展的服务器都无法绕开，而从整个互联网的视角看，全世界电商的交易 TPS 可以轻松上亿。

这个例子带给我们一些思考：为啥几家互联网公司的 TPS 之和可以那么大，服务的用户数规模也极为吓人，而单个互联网公司的 TPS 却很难提升？

究其本质，每家互联网公司都是一个独立的大型单元，他们各自服务自己的用户互不干扰。

这就是单元化的基本特性，任何一家互联网公司，其想要成倍的扩大自己系统的服务能力，都必然会走向单元化之路。

它的本质是分治，我们把广大的用户分为若干部分，同时把系统复制多份，每一份都独立部署，每一份系统都服务特定的一群用户。

以淘宝举例，这样之后，就会有很多个淘宝系统分别为不同的用户服务，每个淘宝系统都做到十万 TPS 的话，N 个这样的系统就可以轻松做到 N*十万的 TPS 了。

LDC 实现的关键就在于单元化系统架构设计，所以在蚂蚁内部，LDC 和单元化是不分家的，这也是很多同学比较困扰的地方，看似没啥关系，实则是单元化体系设计成就了 LDC。

小结：分库分表解决的最大痛点是数据库单点瓶颈，这个瓶颈的产生是由现代二进制数据存储体系决定的（即 I/O 速度）。

单元化只是分库分表后系统部署的一种方式，这种部署模式在灾备方面也发挥了极大的优势。

系统架构演化史

几乎任何规模的互联网公司，都有自己的系统架构迭代和更新，大致的演化路径都大同小异。

最早一般为了业务快速上线，所有功能都会放到一个应用里，系统架构如下图所示：

这样的架构显然是有问题的，单机有着明显的单点效应，单机的容量和性能都是很局限的，而使用中小型机会带来大量的浪费。

随着业务发展，这个矛盾逐渐转变为主要矛盾，因此工程师们采用了以下架构：

阅读全文 »

12306——秒杀系统的艺术

发表于 2020-02-23 | 分类于系统架构

12306抢票,极限并发带来的思考?

每到节假日期间,一二线城市返乡、外出游玩的人们几乎都面临着一个问题：抢火车票!虽然现在大多数情况下都能订到票,但是放票瞬间即无票的场景，相信大家都深有体会。尤其是春节期间，大家不仅使用12306，还会考虑“智行”和其他的抢票软件,全国上下几亿人在这段时间都在抢票。“12306服务”承受着这个世界上任何秒杀系统都无法超越的QPS,上百万的并发再正常不过了！笔者专门研究了一下“12306”的服务端架构,学习到了其系统设计上很多亮点，在这里和大家分享一下并模拟一个例子：如何在100万人同时抢1万张火车票时，系统提供正常、稳定的服务。github代码地址

大型高并发系统架构

高并发的系统架构都会采用分布式集群部署，服务上层有着层层负载均衡，并提供各种容灾手段(双火机房、节点容错、服务器灾备等)保证系统的高可用,流量也会根据不同的负载能力和配置策略均衡到不同的服务器上。下边是一个简单的示意图:

负载均衡简介

上图中描述了用户请求到服务器经历了三层的负载均衡，下边分别简单介绍一下这三种负载均衡：

OSPF(开放式最短链路优先)是一个内部网关协议(Interior Gateway Protocol,简称IGP)。OSPF通过路由器之间通告网络接口的状态来建立链路状态数据库，生成最短路径树，OSPF会自动计算路由接口上的Cost值，但也可以通过手工指定该接口的Cost值，手工指定的优先于自动计算的值。OSPF计算的Cost，同样是和接口带宽成反比，带宽越高，Cost值越小。到达目标相同Cost值的路径，可以执行负载均衡，最多6条链路同时执行负载均衡。
LVS (Linux VirtualServer)，它是一种集群(Cluster)技术，采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。
Nginx想必大家都很熟悉了,是一款非常高性能的http代理/反向代理服务器,服务开发中也经常使用它来做负载均衡。Nginx实现负载均衡的方式主要有三种:轮询、加权轮询、ip hash轮询，下面我们就针对Nginx的加权轮询做专门的配置和测试

Nginx加权轮询的演示

Nginx实现负载均衡通过upstream模块实现，其中加权轮询的配置是可以给相关的服务加上一个权重值，配置的时候可能根据服务器的性能、负载能力设置相应的负载。下面是一个加权轮询负载的配置，我将在本地的监听3001-3004端口,分别配置1，2，3，4的权重:

#配置负载均衡
    upstream load_rule {
       server 127.0.0.1:3001 weight=1;
       server 127.0.0.1:3002 weight=2;
       server 127.0.0.1:3003 weight=3;
       server 127.0.0.1:3004 weight=4;
    }
    ...
    server {
    listen       80;
    server_name  load_balance.com www.load_balance.com;
    location / {
       proxy_pass http://load_rule;
    }
}

我在本地/etc/hosts目录下配置了 www.load_balance.com

的虚拟域名地址，接下来使用Go语言开启四个http端口监听服务，下面是监听在3001端口的Go程序,其他几个只需要修改端口即可：

package main

import (
	"net/http"
	"os"
	"strings"
)

func main() {
	http.HandleFunc("/buy/ticket", handleReq)
	http.ListenAndServe(":3001", nil)
}

//处理请求函数,根据请求将响应结果信息写入日志
func handleReq(w http.ResponseWriter, r *http.Request) {
	failedMsg :=  "handle in port:"
	writeLog(failedMsg, "./stat.log")
}

//写入日志
func writeLog(msg string, logPath string) {
	fd, _ := os.OpenFile(logPath, os.O_RDWR|os.O_CREATE|os.O_APPEND, 0644)
	defer fd.Close()
	content := strings.Join([]string{msg, "\r\n"}, "3001")
	buf := []byte(content)
	fd.Write(buf)
}

我将请求的端口日志信息写到了./stat.log文件当中，然后使用ab压测工具做压测:

阅读全文 »

Hystrix原理与实战

发表于 2020-02-23 | 分类于 Spring

背景

分布式系统环境下，服务间类似依赖非常常见，一个业务调用通常依赖多个基础服务。如下图，对于同步调用，当库存服务不可用时，商品服务请求线程被阻塞，当有大批量请求调用库存服务时，最终可能导致整个商品服务资源耗尽，无法继续对外提供服务。并且这种不可用可能沿请求调用链向上传递，这种现象被称为雪崩效应。

雪崩效应常见场景

硬件故障：如服务器宕机，机房断电，光纤被挖断等。
流量激增：如异常流量，重试加大流量等。
缓存穿透：一般发生在应用重启，所有缓存失效时，以及短时间内大量缓存失效时。大量的缓存不命中，使请求直击后端服务，造成服务提供者超负荷运行，引起服务不可用。
程序BUG：如程序逻辑导致内存泄漏，JVM长时间FullGC等。
同步等待：服务间采用同步调用模式，同步等待造成的资源耗尽。

雪崩效应应对策略

针对造成雪崩效应的不同场景，可以使用不同的应对策略，没有一种通用所有场景的策略，参考如下：

硬件故障：多机房容灾、异地多活等。
流量激增：服务自动扩容、流量控制（限流、关闭重试）等。
缓存穿透：缓存预加载、缓存异步加载等。
程序BUG：修改程序bug、及时释放资源等。
同步等待：资源隔离、MQ解耦、不可用服务调用快速失败等。资源隔离通常指不同服务调用采用不同的线程池；不可用服务调用快速失败一般通过熔断器模式结合超时机制实现。

综上所述，如果一个应用不能对来自依赖的故障进行隔离，那该应用本身就处在被拖垮的风险中。因此，为了构建稳定、可靠的分布式系统，我们的服务应当具有自我保护能力，当依赖服务不可用时，当前服务启动自我保护功能，从而避免发生雪崩效应。本文将重点介绍使用Hystrix解决同步等待的雪崩问题。

初探Hystrix

Hystrix [hɪst’rɪks]，中文含义是豪猪，因其背上长满棘刺，从而拥有了自我保护的能力。本文所说的Hystrix是Netflix开源的一款容错框架，同样具有自我保护能力。为了实现容错和自我保护，下面我们看看Hystrix如何设计和实现的。

Hystrix设计目标：

对来自依赖的延迟和故障进行防护和控制——这些依赖通常都是通过网络访问的
阻止故障的连锁反应
快速失败并迅速恢复
回退并优雅降级
提供近实时的监控与告警

Hystrix遵循的设计原则：

防止任何单独的依赖耗尽资源（线程）
过载立即切断并快速失败，防止排队
尽可能提供回退以保护用户免受故障
使用隔离技术（例如隔板，泳道和断路器模式）来限制任何一个依赖的影响
通过近实时的指标，监控和告警，确保故障被及时发现
通过动态修改配置属性，确保故障及时恢复
防止整个依赖客户端执行失败，而不仅仅是网络通信

Hystrix如何实现这些设计目标？

使用命令模式将所有对外部服务（或依赖关系）的调用包装在HystrixCommand或HystrixObservableCommand对象中，并将该对象放在单独的线程中执行；
每个依赖都维护着一个线程池（或信号量），线程池被耗尽则拒绝请求（而不是让请求排队）。
记录请求成功，失败，超时和线程拒绝。
服务错误百分比超过了阈值，熔断器开关自动打开，一段时间内停止对该服务的所有请求。
请求失败，被拒绝，超时或熔断时执行降级逻辑。
近实时地监控指标和配置的修改。

阅读全文 »

Spring事务失效的 8 大原因

发表于 2020-02-23 | 分类于 Spring

数据库引擎不支持事务

这里以 MySQL 为例，其 MyISAM 引擎是不支持事务操作的，InnoDB 才是支持事务的引擎，一般要支持事务都会使用 InnoDB。

根据 MySQL 的官方文档：

https://dev.mysql.com/doc/refman/5.5/en/storage-engine-setting.html

从 MySQL 5.5.5 开始的默认存储引擎是：InnoDB，之前默认的都是：MyISAM，所以这点要值得注意，底层引擎不支持事务再怎么搞都是白搭。

没有被 Spring 管理

如下面例子所示：

// @Service
public class OrderServiceImpl implements OrderService {

    @Transactional
    public void updateOrder(Order order) {
        // update order
    }

}

如果此时把 @Service 注解注释掉，这个类就不会被加载成一个 Bean，那这个类就不会被 Spring 管理了，事务自然就失效了。

方法不是 public 的

以下来自 Spring 官方文档：

When using proxies, you should apply the @Transactional annotation only to methods with public visibility. If you do annotate protected, private or package-visible methods with the @Transactional annotation, no error is raised, but the annotated method does not exhibit the configured transactional settings. Consider the use of AspectJ (see below) if you need to annotate non-public methods.

大概意思就是 @Transactional 只能用于 public 的方法上，否则事务不会失效，如果要用在非 public 方法上，可以开启 AspectJ 代理模式。

自身调用问题

来看两个示例：

@Service
public class OrderServiceImpl implements OrderService {

    public void update(Order order) {
        updateOrder(order);
    }

    @Transactional
    public void updateOrder(Order order) {
        // update order
    }

}

update方法上面没有加 @Transactional 注解，调用有 @Transactional 注解的 updateOrder 方法，updateOrder 方法上的事务管用吗？

再来看下面这个例子：

@Service
public class OrderServiceImpl implements OrderService {

    @Transactional
    public void update(Order order) {
        updateOrder(order);
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void updateOrder(Order order) {
        // update order
    }

}

这次在 update 方法上加了 @Transactional，updateOrder 加了 REQUIRES_NEW 新开启一个事务，那么新开的事务管用么？

这两个例子的答案是：不管用！

因为它们发生了自身调用，就调该类自己的方法，而没有经过 Spring 的代理类，默认只有在外部调用事务才会生效，这也是老生常谈的经典问题了。

这个的解决方案之一就是在的类中注入自己，用注入的对象再调用另外一个方法，这个不太优雅，另外一个可行的方案可以参考《Spring 如何在一个事务中开启另一个事务？》这篇文章。

数据源没有配置事务管理器

@Bean
public PlatformTransactionManager transactionManager(DataSource dataSource) {
    return new DataSourceTransactionManager(dataSource);
}

如上面所示，当前数据源若没有配置事务管理器，那也是白搭！

阅读全文 »