高并发秒杀系统分析

Dear 丶 2022-03-22 03:38 427阅读 0赞

学习自慕课网[Java高并发秒杀API之业务分析][Java_API]

# 1 秒杀业务分析 #

## 1.1 秒杀系统业务流程 ##

![20190128174653894.png][]

秒杀系统的核心——库存的处理

## 1.2 用户针对库存业务分析 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70][]

## 1.3 什么是购买行为 ##

![20190128175007128.png][]

## 1.4 为什么需要事务 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 1][]

## 1.5 故障责任是谁？ ##

![20190128175329993.png][]

## 1.6 关于数据落地——MySQL VS NoSQL ##

NoSQL对于事务的支持还不完善

而事务机制依然是目前最可靠的落地方案

MySQL内部的事务机制可以帮助我们准确可靠的完成减库存记录，用户购买行为,,,,,,

# 2 MySQL实现秒杀难点分析 #

## 2.1 “竞争”问题 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 2][]

## 2.2 事务 ##

Start Transaction

Update 库存数量 —— 竞争主要出现在该步

Insert购买明细

Commit

## 2.3 行级锁 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 3][]

# 3 实现哪些秒杀功能 #

## 3.1 天猫的秒杀库存系统 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 4][]

![20190129170946359.png][]

## 3.2 秒杀功能 ##

![20190129171005208.png][]

# 4 高并发发生在哪 #

进入详情页，调用系统时间，秒杀没开始就进入倒计时。若秒杀开始就调用地址暴露接口，拿到秒杀地址，执行秒杀操作，返回结果。

![20190130095617406.png][]

红色代表会出现高并发。

## 4.1 为什么要单独获取系统时间 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 5][]

秒杀没开始时，用户会不断刷新页面，而详情页的静态资源是部署在CDN中的，即用户访问的详情页html，js，css是部署在CDN节点中的，而不用去访问系统服务器，导致无法获取系统时间。因此需要单独写一个请求去获取系统的时间。

但是，**获取系统时间不用优化**。

Java访问一次内存的时间大约为1纳秒，在程序中new 一个日期对象，再返回给用户，不考虑GC的影响，1s大约能操作1亿次。

## 4.2 CDN是what？ ##

参考：[通过CDN为网站加速][CDN]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 6][]

## 4.3 秒杀地址接口分析 ##

无法使用CDN缓存，因为秒杀地址返回的数据是在变化的，秒杀没开始时，秒杀开始，秒杀关闭都对应不同的秒杀地址返回的数据。它适合放在服务器端缓存，redis等。

![20190130101444924.png][]

获取秒杀对象，缓存有就从缓存里拿，通过判断系统时间与秒杀设定时间，来决定返回的数据。

![20190130101621686.png][]

## 4.4 秒杀操作优化分析 ##

若大量用户访问redis，命中，直接返回，但在缓存实现库存的增减不可靠。需要依靠MySQL的事务来保证数据的一致性。

对于热点商品，会有大量用户去秒杀，MySQL库存的数据会出现大量的update

![20190130102746593.png][]

## 4.5 其他方案分析 ##

采用原子计数器（可通过redis、NoSQL来实现）来记录商品的库存，记录对库存的操作信息，即哪个用户减的库存，作为一条消息放入分布式MQ（阿里的RocketMQ相对强大，支持事务）中。后端的服务会去消费MQ中的消息，并更新到MySQL。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 7][]

这个架构可以扛着非常高的并发，但是成本高。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 8][]

NoSQL（相对不稳定）和MQ都是分布式服务，需要强大的运维团队去支撑。

减库存失败时的回滚方案。

用户重复秒杀。

## 4.6 为什么不用MySQL来解决 ##

有人说MySQL低效。那MySQL真的低效吗？

### **4.6.1 测试：用同一个id执行update减库存** ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 9][]

即同一个商品1s可以卖4万次

### 4.6.2 java控制事务行为分析 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 10][]

行锁在Commit之后释放，优化方向是减少行级锁持有时间

## 4.6.3 延迟分析 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 11][]

**异地机房**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 12][]

## 4.7 如何判断Update更新库存成功 ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 13][]

## 4.8 如何放到MySQL服务端 ##

![20190130150614796.png][]

## 4.9 优化总结 ##

![20190130151523981.png][]

# 5 Redis后端缓存优化编码 #

**使用Redis优化“地址暴露接口”**

public class RedisDao {
    	private final JedisPool jedisPool;
    
    	public RedisDao(String ip, int port) {
    		jedisPool = new JedisPool(ip, port);
    	}
            //运行期对象
    	private RuntimeSchema<Seckill> schema = RuntimeSchema.createFrom(Seckill.class);
    
            // 采用自定义序列化，把对象转化成二进制字节数保存在redis
    	// protostuff: pojo.
    
            //get-byte[]-反序列化-Object(Seckill)
    	public Seckill getSeckill(long seckillId) {
    		// redis操作逻辑
    		try {
                            //jedis集成了redis的命令操作，封装了redis的java客户端
    			Jedis jedis = jedisPool.getResource();
    			try {
    				String key = "seckill:" + seckillId;
    				// 并没有实现哪部序列化操作
    				byte[] bytes = jedis.get(key.getBytes());
    				// 缓存重获取到
    				if (bytes != null) {
    					Seckill seckill = schema.newMessage();
    					ProtostuffIOUtil.mergeFrom(bytes, seckill, schema);
    					// seckill被反序列化
    					return seckill;
    				}
    			} finally {
    				jedis.close();
    			}
    		} catch (Exception e) {}
    		return null;
    	}
    
            //对象-序列化-byte[]
    	public String putSeckill(Seckill seckill) {
    		try {
    			Jedis jedis = jedisPool.getResource();
    			try {
    				String key = "seckill:" + seckill.getSeckillId();
    				byte[] bytes = ProtostuffIOUtil.toByteArray(seckill, schema,
    						LinkedBuffer.allocate(LinkedBuffer.DEFAULT_BUFFER_SIZE));
    				// 超时缓存
    				int timeout = 60 * 60;// 1小时
    				String result = jedis.setex(key.getBytes(), timeout, bytes);
    
    				return result;
    			} finally {
    				jedis.close();
    			}
    		} catch (Exception e) {}
    		return null;
    	}
    }

public class RedisDaoTest {
    	private final Logger logger = LoggerFactory.getLogger(this.getClass());
    
    	private long id = 1001;
    
    	@Autowired
    	private RedisDao redisDao;
    
    	@Autowired
    	private SeckillDao seckillDao;
    
    	@Test
    	public void testSeckill() {
                    //先从看看缓存有没有
    		Seckill seckill = redisDao.getSeckill(id);
    		if (seckill == null) {
                            //缓存没有就从数据库里拿
    			seckill = seckillDao.queryById(id);
    			if (seckill != null) {
                                    //再存入缓存
    				String result = redisDao.putSeckill(seckill);
    				logger.info("result={}", result);
                                    //再从缓存里拿
    				seckill = redisDao.getSeckill(id);
    				logger.info("seckill={}", seckill);
    			}
    		}
    	}
    }

# 6 秒杀操作-并发优化 #

用户的秒杀操作分为两步：减库存、插入购买明

## **6.1 回顾事务执行** ##

![20190131135816267.JPG][]

## **6.2 简单优化，先insert再update** ##

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 14][]

### 为什么要先insert再update ###

更新操作的时候给行加锁，插入并不会加锁，

若更新操作在前，那么就需要执行完更新和插入以后事务提交或回滚才释放锁。

若插入在前，更新在后，那么只有在更新时才会加行锁，之后在更新完以后事务提交或回滚释放锁。

插入是可以并行的，而更新由于会加行级锁是串行的。

更新在前，加锁和释放锁之间有两次的网络延迟和GC，

插入在前，加锁和释放锁之间只有一次的网络延迟和GC，也就是减少的持有锁的时间。

这里先insert并不是忽略了库存不足的情况，而是因为insert和update是在同一个事务里，光是insert并不一定会提交，只有在update成功才会提交，所以并不会造成过量插入秒杀成功记录。

## 6.3 深度优化 ##

前边通过调整insert和update的执行顺序来实现简单优化，但依然存在着Java客户端和服务器通信时的网络延迟和GC影响，我们可以将执行秒杀操作时的insert和update放到MySQL服务端的存储过程里，而Java客户端直接调用这个存储过程，这样就可以避免网络延迟和可能发生的GC影响。另外，由于我们使用了存储过程，也就使用不到Spring的事务管理了，因为在存储过程里我们会直接启用一个事务。

写一个存储过程procedure，然后再MySQL控制台执行它

再修改Java程序，调用存储过程

### 存储过程 ###

1 存储过程Procedure是一组为了完成特定功能的SQL语句集合，经编译后存储在数据库中，用户通过指定存储过程的名称并给出参数来执行。

2 存储过程只在创造时进行编译，以后每次执行存储过程都不需再重新编译，而一般 SQL 语句每执行一次就编译一次,所以使用存储过程可提高数据库执行速度。

3 数据库专业人员可以随时对存储过程进行修改，但对应用程序源代码却毫无影响，从而极大的提高了程序的可移植性。

# 7 系统部署架构 #

![20190131143515324.png][]

**CDN**：放置一些静态化资源。一些js依赖直接用公网的CDN，自己开发的一些页面也做静态化处理推送到CDN。用户在CDN获取到的数据不需要再访问我们的服务器，动静态分离可以降低服务器请求量。比如秒杀详情页，做成HTML放在CDN上，动态数据可以通过Ajax请求后台获取。

**Nginx**：作为http服务器，响应客户请求，为后端的servlet容器做反向代理，以达到负载均衡的效果。

**Redis**：用来做服务器端的缓存，通过Jedis提供的API来达到热点数据的一个快速存取的过程，减少数据库的请求量。

**MySQL**：保证秒杀过程的数据一致性与完整性。

智能DNS解析+智能CDN加速+Nginx并发+Redis缓存+MySQL分库分表  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 15][]

一部分的流量会被CDN缓存拦截，另一部分请求会去访问服务器

对Nginx服务器集群做负载均衡SLB

同一个秒杀id放在同一个数据库中，事务在同一个数据库中生效，保证同一个秒杀单在同一个数据库中完成事务

# 8 **阿里双11秒杀背后的技术** #

[![ec568050fa9ab664da17982304519b29.jpg-wh_651x-s_1872100465.jpg][]][ec568050fa9ab664da17982304519b29.jpg-wh_651x-s_1872100465.jpg]

## **8.1 阿里双11背后的技术** ##

### **8.1.1 云计算** ###

利用云计算弹性能力，支撑交易峰值每秒32.5万笔、支付峰值每秒25.6万笔的混合云弹性架构。

### **8.1.2 分布式消息引擎** ###

在双11当天实现万亿级消息流转。

### **8.1.3 Docker技术** ###

交易核心应用容器化撑起双11交易下单峰值，解放资源的超大规模Docker化技术。

### **8.1.4 在线交易的数据实时和离线计算能力** ###

支撑全球最大规模在线交易的数据实时和离线计算能力，包括承载阿里巴巴集团核心大数据的离线计算平台，以及双十一保证每秒处理亿条日志的计算。

### **8.1.5 阿里人工智能** ###

在搜索、推荐以及客服场景下的创新应用，包括人工智能赋能的数千家品牌商家店铺的个性化运营和粉丝会员的精准营销。

### **8.1.6 VR技术** ###

虚拟购物环境背后的VR技术。

### **8.1.7 前端技术** ###

应对前端极限挑战的淘宝直播首屏秒开，以及应用世界级开源跨平台移动开发工具Weex实现双11会场几近全覆盖，实现全网首屏渲染完美践行“秒开”体验。

### **8.1.8 监控技术** ###

千万量级监控项，PB级监控数据，亿级报警通知背后的技术。

### **8.1.9 物流技术** ###

菜鸟通过包裹预测、供应链入库、订单下沉、订单路由调度、电子面单及智能分单，以及末端小件员，涉及十亿级包裹的双11之战。

## **8.2 双11秒杀架构设计思路** ##

秒杀系统特点是并发量极大，但实际秒杀成功的请求数量却很少，所以如果不在前端拦截很可能造成数据库读写锁冲突，甚至导致死锁，最终请求超时。

很重要的设计思路：将请求拦截在系统上游，降低下游压力。

### **8.2.1 充分利用分布式缓存(tair+redis)** ###

利用缓存可极大提高系统读写速度。

### **8.2.2 充分利用消息中间件削峰** ###

这里有相关的阿里消息中间件(Notify和MetaQ)，以及开源的(ActiveMQ、Kafka等)。

消息队列可以削峰，将拦截大量并发请求，这也是一个异步处理过程，后台业务根据自己的处理能力，从消息队列中主动的拉取请求消息进行业务处理。

### **8.2.3 前端设计优化** ###

*  页面静态化：将活动页面上的所有可以静态的元素全部静态化，并尽量减少动态元素，通过CDN来抗峰值。
 *  禁止重复提交：用户提交之后按钮置灰，禁止重复提交，防止一秒钟内多次写入数据库。
 *  用户限流：在某一时间段内只允许用户提交一次请求，比如可以采取IP限流

### **8.2.4 后端设计优化** ###

*  服务端控制器层(网关层)
 *  限制uid(UserID)访问频率：我们上面拦截了浏览器访问的请求，但针对某些恶意攻击或其它插件，在服务端控制层需要针对同一个访问uid，限制访问频率。
 *  服务层：上面只拦截了一部分访问请求，当秒杀的用户量很大时，即使每个用户只有一个请求，到服务层的请求数量还是很大。比如我们有100W用户同时抢100台手机，服务层并发请求压力至少为100W。
 *  采用消息队列缓存请求：既然服务层知道库存只有100台手机，那完全没有必要把100W个请求都传递到数据库啊，那么可以先把这些请求都写到消息队列缓存一下，数据库层订阅消息减库存，减库存成功的请求返回秒杀成功，失败的返回秒杀结束。
 *  利用缓存应对读请求：比如双11秒杀抢购，是典型的读多写少业务，大部分请求是查询请求，所以可以利用缓存分担数据库压力。
 *  利用缓存应对写请求：缓存也是可以应对写请求的，比如我们就可以把数据库中的库存数据转移到Redis缓存中，所有减库存操作都在Redis中进行，然后再通过后台进程把Redis中的用户秒杀请求同步到数据库中。

### **8.2.5 数据库层** ###

数据库层是最脆弱的一层，一般在应用设计时在上游就需要把请求拦截掉，数据库层只承担“能力范围内”的访问请求。所以，上面通过在服务层引入队列和缓存，让最底层的数据库高枕无忧。

淘宝在09年的时候就已经提前把数据库按照业务进行垂直拆分，再结合业务需要进行水平拆分。现在对数据库的拆分，都是利用数据库层中间件(淘宝 tddl)，来进行无缝对数据库的侵入设计。

除此以外还会涉及到分布式小文件存储以及搜索引擎，以及服务器集群监控等技术。

[Java_API]: https://www.imooc.com/learn/587
[20190128174653894.png]: /images/20220322/ce1afbf411da4cc9a9d1cef8aa03c97e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70]: /images/20220322/578a6c00f6354fd888e6581e7f340b13.png
[20190128175007128.png]: /images/20220322/9be36cd697ef4f238a16e7080d811bdf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 1]: /images/20220322/a8dcc0c9bbaf4add89be50538d2c4190.png
[20190128175329993.png]: /images/20220322/5ed83dac91584727a6bb2cf773ad61d4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 2]: /images/20220322/cdd6bff6a46d4d6f8416910265099f2f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 3]: /images/20220322/cc5576bd43f24a2788defb00d88eb21a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 4]: /images/20220322/891603ee8d0c405bad3a3bd21c410ed9.png
[20190129170946359.png]: /images/20220322/f6fff9616b134103a33da311b56e11e1.png
[20190129171005208.png]: /images/20220322/c0c25d41a8234ca89116c5f80eccc990.png
[20190130095617406.png]: /images/20220322/9ae771b161a14c3d93223d389f1a493d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 5]: /images/20220322/782047c7e1284113ad877b58eeea4474.png
[CDN]: https://blog.csdn.net/wydyd110/article/details/79958099
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 6]: /images/20220322/59886fe5a7b84e88874e58076a99f441.png
[20190130101444924.png]: /images/20220322/9690832e93be40499bdf31ff98c04f21.png
[20190130101621686.png]: /images/20220322/99695ba20ab341f3a192ba59944723e5.png
[20190130102746593.png]: /images/20220322/76db44dadd6043aaaa6b93dbac9a8570.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 7]: /images/20220322/b93caecdf6f74923b34ab163476e23e2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 8]: /images/20220322/03349bb0b1884c39b65285068e4cde13.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 9]: /images/20220322/f243310b478f4c0e95eec0aae17e7086.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 10]: /images/20220322/aa10c345e95242c69b426fa7905ab0ab.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 11]: /images/20220322/c32ea26b34e64e8b886b981b90ae9369.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 12]: /images/20220322/376912a65e4646a69b771af9ccecf459.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 13]: /images/20220322/fde92f6db7e34a4f9d9de7d310eb6584.png
[20190130150614796.png]: /images/20220322/ad5c7f1c3ff74223a0f05af244f8f719.png
[20190130151523981.png]: /images/20220322/4a54bbd6e8c946b1aa95054cf2602a71.png
[20190131135816267.JPG]: /images/20220322/47a490aacc1245a1a353b9de65cbaf0f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 14]: /images/20220322/e9ac546019c74d2cae495d9031ceb116.png
[20190131143515324.png]: /images/20220322/0f188eefe9154e7da870cfb6200e3385.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d5ZHlkMTEw_size_16_color_FFFFFF_t_70 15]: /images/20220322/94b2f71b43c74a15ae7440a1ecd80477.png
[ec568050fa9ab664da17982304519b29.jpg-wh_651x-s_1872100465.jpg]: /images/20220322/36a56958b1ad40a482e6262692e91390.png