分布式秒杀系统构建

已于 2022-07-31 10:18:30 修改
阅读量2.4k 收藏 10
点赞数 3
分类专栏： advance 文章标签： 秒杀 高并发 电商 分布式 微服务
于 2022-04-20 00:34:25 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/qq_52163230/article/details/124156358
版权

目录

主要解决问题

  1. 高并发
  2. 线程安全（超卖）
  3. 事务一致性（分布式事务）
  4. 防止提前下单
  5. 倒计时实现

项目架构

在这里插入图片描述

数据库设计

CREATE DATABASE shop

-- 商品表
CREATE TABLE goods(
	id INT PRIMARY KEY AUTO_INCREMENT,
	title VARCHAR(100) NOT NULL,
	info TEXT,
	price DECIMAL(10,2),
	save INT NOT NULL,
	begin_time TIMESTAMP NOT NULL,
	end_time TIMESTAMP NOT NULL
);

-- 订单表
CREATE TABLE orders(
	id INT PRIMARY KEY AUTO_INCREMENT,
	oid VARCHAR(30) NOT NULL UNIQUE,
	gid INT NOT NULL,
	uid INT NOT NULL,
	gnumber TINYINT NOT NULL DEFAULT 1,
	all_price DECIMAL(10,2) NOT NULL,
	create_time TIMESTAMP DEFAULT NOW(),
	STATUS TINYINT DEFAULT 0
)

项目启动

windows+VMWare启动

Nacos
cmd D:
cd Program Files\nacos\bin
startup.cmd -m standalone
http://192.168.52.1:8848/nacos/index.html
启动Sentinel
cd Program Files
java -jar sentinel-dashboard-1.8.1.jar
localhost:8080账号密码sentinel
Reids
启动CentOS8
cd usr/local/redis/bin
./redis-server redis.conf
./redis-cli
auth 000
RabbitMQ
启动CentOS7
/usr/local/software/rabbitmq_software/rabbitmq_server-3.7.16/sbin/rabbitmq-server -detached
http://192.168.32.129:15672/
启动前后端各服务

云服务启动

Nacos
cd /usr/local/nacos/bin
startup.cmd -m standalone
http://47.94.56.33:8848/nacos/index.html
启动Sentinel
cd usr/local/sentinel
java -Dserver.port=8849 -Dcsp.sentinel.dashboard.server=localhost:8849 -Dproject.name=sentinel-dashboard -jar sentinel-dashboard-1.8.1.jar
http://47.94.56.33:8849/#/login账号密码sentinel
RabbitMQ
http://47.94.56.33:15672/

1.后端返回秒杀时间

进入主页面后向服务器发起请求，获取当前时间并计算出五个场次的集合

  1. DateUtil.getSecKillTime(i)，参数为场次
  2. 获取当前时间，时位如果为奇数就-1，分秒位 置0
  3. 加上 场次*2 为当前时间并返回
  4. i从0到5循环获取五次，放到一个集合中返回

为什么不用js
如果用前端js，时间就参考本机的时间，为了保证所有时间一致，使用服务器返回时间；基本所有时间有关的都由服务器返回；

可以设定一个专门提供时间的服务器，这样各个服务器获取的当前时间都一致

2.解决跨域问题

浏览器和gateway网关之间会产生跨域问题

因为浏览器的请求会先到网关

spring:
  cloud:
    gateway:
      # gateway的全局跨域请求配置
      globalcors:
        cors-configurations:
          '[/**]':
            allow-credentials: true
            allowed-originPatterns: "*"
            allowed-headers: "*"
            allowed-methods:
              - OPTIONS
              - GET
              - POST

3.Redis序列化

序列化问题：增加配置类

@Configuration
public class RedisConfig extends CachingConfigurerSupport {
    @Bean
    public RedisCacheConfiguration redisCacheConfiguration() {
        RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig();
        config=config.serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(RedisSerializer.json()));
        return config;
    }
}

4.秒杀倒计时

  1. 客户端进入商品页面，随即从服务器获取时间
  2. 获取该场次时间，相减获得时间差
  3. 使用setTimeout()让服务器时间每隔一秒加一秒
  4. 时间差小于等于0，则改变按钮，开始秒杀

有一个专门处理时间的服务器，这个服务器可以被其他服务调用，这样保证了在集群情况下，各个服务器中的时间误差达到微妙级别

5.如何防止提前下单

方案一：
下单前，查询缓存，获得当前商品的秒杀开始时间，看当前时间是否在秒杀时间之内，就可以下单；（redis中key过多，需要判断）

方案二：
通过Redis记录当前秒杀时间段的商品集合，这样Redis中key不会太多

  1. 管理员添加秒杀商品，存入数据库，再在Rides的该时间段的集合中加入该商品
  2. Redis开定时任务，时间到了更变当前秒杀商品集合
  3. 有下单请求，先在Redis的当前时间集合中查看是否有该商品Id，有就说明该商品正在秒杀时间段，完成购买；没有就说明不在，返回错误。
    在这里插入图片描述

6.如何防止重复提交

方案一：
商品页面生成时，会在页面隐藏一个UUID，提交请求后把这个UUID存入Redis，如果这个UUID已存在，就是重复提交
（只能防止误触碰；如果有人恶意提交不能判断）

方案二：
提交必须输入验证码

  1. 防止重复提交
  2. 防止恶意提交（秒杀器、脚本）（普通验证码容易被破解；现在是行为验证码）
  3. 拉长服务器的请求处理时间

7.网关限流

计数器算法

在redis中计数，每次请求计数器减一，达到0，停止接收请求，设置过期时间，这样可以控制在单位时间内接收的请求数量。

如果单位时间请求分布不均匀，比如集中在第一秒的前半段和第二秒的后半段，会超出阈值

漏桶算法

  1. 水（请求）从上方倒入水桶，从水桶下方流出（被处理）；
  2. 来不及流出的水存在水桶中（缓冲），以固定速率流出；
  3. 水桶满后水溢出（丢弃）。

这个算法的核心是：缓存请求、匀速处理、多余的请求丢弃。

漏桶算法对突发流量不做额外处理，无法应对存在突发特性的流量

*令牌桶算法

按照一定的速率往令牌桶中放令牌，请求来了就拿走令牌，发现没有令牌了就是限流了。还可以根据其他因素限流，比如说同一个请求普通用户要3个令牌，vip只要一个令牌，这样vip用户被限流的概率就比普通用户低。

根据URI对访问资源的请求限流，项目对获取验证码请求 和 秒杀下单请求分别限流，一个URI对应一个令牌桶。

桶结构
令牌桶可以看成一个Map集合，key 是 请求的URI，值又是一个Map，也就是桶结构，有四个键值对 对应 桶的四个参数。

  1. 当前剩余的令牌数
  2. 最大令牌数
  3. 每秒产生的令牌数
  4. 下一次可以产生令牌的时间

令牌桶要放到Redis中，服务集群下每个节点都是使用的这个桶，hash结构，key为需要限流的关键属性（URI），value为桶参数

实现
用户发出请求，路由网关先查询Redis中是否存在令牌桶，没有就创建这个桶，有就判断桶中当前令牌数是否大于这次请求需要的令牌数，如果剩余令牌足够就取领牌（hdecr uri tokens）；这是两条命令，会发生安全性问题。Redis执行命令是单线程可以不用加锁，使用lua脚本或Redis事务保证隔离性

设计要点

  1. 令牌的生成方式：不用线程添加（桶多个线程多增大开销），而是每次请求主动计算要生成多少：每次请求都会写带当前时间，用当前时间减下一次可以生成令牌的时间，用这个时间差*每秒生成令牌桶的数量，再加上现有令牌数，就更新了现有令牌数；（不能大于最大令牌数）；同时更新下一次生成令牌的时间
  2. 令牌的预支设计：为了让重量级的请求有机会执行；预支的是时间，而不是令牌数；比如每秒生成4个令牌，如今我有3个令牌，这个请求要5个令牌，就会让当前令牌置零，预支到0.5秒后的时间，而在这0.5秒之中如果有个请求在0.2需要预支令牌，告知它需要等待0.3秒（或者直接限流）；
    在这里插入图片描述

获取令牌流程
比如说我一个令牌桶，当前1个令牌，最大10个令牌，每秒产生5个令牌，当前时间是0:00:00。0:00:01来了个请求，计算出前令牌数就是6（这里要保证不能大于最大令牌数），这个请求要申请3个令牌，够用，直接当前令牌数-3。
如果要8个令牌，不够用，就预支2个令牌，这时候令牌桶数量置为0，将下一次产生令牌的时间置为
0:00:01+2/5=0:00:01.40，也就是在这个时间点再+5个令牌，在到这个时间点前的请求看到的当前令牌数都是0，就没申请到，这个请求就被限流了。（getTokenNow()，没拿到就限流，不等待）

java中怎么做
给网关加上一个过滤器类实现GatewayFilter接口。用ConcurrentHashMap保存桶集合，键是请求的url，值是当前url对应的令牌桶，从map找是否有这个桶，没有就初始化，要用并发安全的map。

lua脚本

redis执行命令单线程特性，保证对redis多个操作的隔离性，实现无锁化线程安全

eval script numkeys key... arg...

eval：固定写法，代表要执行一个lua脚本
script：脚本内容，lua语言代码
numkeys：脚本中key变量的数量
key…：实际的key
arg…：其他参数

script：redis.call('','','')参数就是redis指令用逗号隔开

存定参数
在这里插入图片描述
存不定参数，KEY[1]，代表key 的数组，ARGV[1]是值的数组，key变量长度为1就只把后面1个参数放到key数组，其余放到ARGV数组
在这里插入图片描述
返回
在这里插入图片描述
判断
在这里插入图片描述

8.请求下单数据一致性

  1. 使用sync加锁，锁在业务层，但是事务靠aop加强，如果锁释放事务没提交却有线程修改，还是会出现问题，耗时15s（锁加的范围一定要大于事务，否则事务没有提交锁就释放了）
  2. 使用redis分布式锁，用商品id作标识上锁，在超高并发下，大量的加锁请求超时失败重试，IO消耗性能非常差，107s
  3. 使用mysql事务+读排他锁：开启数据库事务，虽然事务保证ACID但是事务之间不可间，读不加锁就会同时读，所以使用select ... for update给查询加排他锁，然后查出来库存进行判断并扣减库存和生成订单，保证读和修改 的原子性，耗时11s（数据库的压力非常大）
  4. mysql乐观锁：尝试扣减库存，修改时这条数据会自动加锁，返回是否被修改，扣减成功了再生成订单，耗时6s （同样数据库压力过大）在这里插入图片描述

Redis单线程+Lua

因为将各个商品的缓存预先存入redis，查询库存和减库存这两个操作都是操作redis，防止超卖就是保证这两个操作的隔离性，不会被打断；

利用redis单线程特性和lua脚本

redis的lua脚本：把库存放到redis，使用lua脚本在reids查询并下单，最后把redis数据同步到数据库，无锁，耗时4s

9.多线程异步处理减库存和生成订单

如果不使用消息队列实现异步。

在redis判断超卖后，将信息先存入redis，等到商品库存扣到0或秒杀结束，调用一个方法实现@Sync注解，然后这个方法中new一个线程去从redis拿然后完成减库存和生成订单，这样就会异步处理这个线程。

减库存就是拿到redis中库存数然后直接存入数据库

生成订单采用批量insert的方式，sql就是用insert into order values <foreach></foreach>的方式插入保存；因为sql语句长度有限，所以500保存一次
在这里插入图片描述
在这里插入图片描述
因为redis是AP架构的，是异步持久化或者主从复制的，会出现信息丢失，会造成不可逆的后果，所以不能放到redis里。

  1. 分布式事务最终一致性保证，可以保证发出的消息一定能收到（发布确认+消息持久化+手动应答）
  2. 请求削峰，放到mq里慢慢消费

10.sql出错导致feign超时调用

sql错误，导致消息一直不能被消费，消费者就一直消费（.ListenerExecutionFailedException），feign调用超时出错

11.sentinel防服务雪崩

流量控制

限制业务访问的qps，避免服务因流量突增而故障，预防服务挂掉

获取秒杀地址的请求、获取验证码的请求在gateway进行令牌桶限流；

  1. 用户查询商品和减库存操作都调用商品服务，所以使用关联模式限流，当减库存的请求达到一定数量，对查询限流，返回友好提示。
  2. 用户查询订单、生成订单 都会查询商品（getGoodsById），两个controller层的方法 链路访问同一资源，在getGoodsById()使用链路模式限流，对用户查询订单这个链路限流。

熔断降级

  1. 订单服务依赖商品服务，对feign的调用进行慢调用比例统计：超过300ms的认为是慢调用，在5秒内，慢调用的次数大于10或者慢调用比例大于0.5，对该商品服务熔断，熔断时间为5s，这时断路器记性half-open状态，5s后再放一次请求实验一下。调用失败走失败逻辑
  2. 订单服务还依赖用户服务，查询订单的时候要查用户，同样使用这种方式进行熔断降级

12.管理员修改商品问题

管理员在对商品进行操作时，先判断该商品是否已经在秒杀时间段，如果在则不能操作；

添加商品库存：数据库添加，成功后缓存中添加

修改和删除时都要删除相应的缓存

13.隐藏秒杀接口

  1. 点击秒杀按钮不直接进行秒杀请求，而是获取秒杀接口地址
    015fe6a3552336bb298ff8af9333523a.png
  2. 新秒杀接口地址其实就是在原来基础上拼接一个 md5加密的uuid的唯一加密字符串，然后将这个字符串返回给用户；并存入redis，键由uid+gid组成，并设置过期时长；
    657ff8bc63d29c64d440cfafc80af50f.png
  3. 调用秒杀方法，将返回的字符串拼接成新的请求路径，这样这个路径就是唯一的
    8f5f2be71648f8173872e604a5cb45bf.png
  4. 调用真正的秒杀接口，判断这个路径是否存在，若存在则进行秒杀服务
    dad2a508deae2c0bfdf1a7a29ace228b.png

14.秒杀验证码

为了防止使用脚本一次提交大量请求，隐藏接口地址不能完全避免；所以让用户在进入商品页面的时候通过 gid 和 uid 得到一个图片验证码，这个验证码是从gitee上下载的验证码组件，它将一个验证码和答案一一对应，我这里将图片返回到用户界面，答案存放在redis中并设置过期时长，用户在获取秒杀请求url时就需要携带验证码答案 通过 gid和uid 在redis中校验验证码是否正确；

<!--验证码-->
<dependency>
    <groupId>com.github.whvcse</groupId>
    <artifactId>easy-captcha</artifactId>
    <version>1.6.2</version>
</dependency>

生成验证码接口

@RequestMapping("/captcha/{gid}/{uid}")
public void verifyCode(@PathVariable("gid") Integer gid, @PathVariable("uid") Integer uid, HttpServletResponse response) {
    //设置请求头为图片类型
    response.setContentType("image/jpg");
    response.setHeader("Pargam", "No-cache");
    response.setHeader("Cache-Control", "no-cache");
    response.setDateHeader("Expires", 0);
    //生成验证码,将验证码放入redis
    ArithmeticCaptcha captcha = new ArithmeticCaptcha(130, 32, 3);
    redisTemplate.opsForValue().set("captcha:" + uid + ":" + gid, captcha.text(), 300, TimeUnit.SECONDS);
    try {
        captcha.out(response.getOutputStream());
    } catch (IOException e) {
        log.error("验证码生成失败");
        e.printStackTrace();
    }
}

前端请求

//刷新验证码
refreshCaptcha() {
	var _this = this;
	this.$http({
		method: 'GET',
		url: "/kill/captcha/" + _this.gid + "/" + _this.uid,
		responseType: 'blob',
	}).then(res => {
		const {
			data,
			headers
		} = res
		const blob = new Blob([data], {
			type: headers['content-type']
		})
		_this.imgsrc = window.URL.createObjectURL(blob)
	})
}

校验验证码

public boolean checkCaptcha(Integer uid, Integer gid, String captcha) {
    String redisCaptcha = redisTemplate.opsForValue().get("captcha" + uid + "-" + gid);
    if (redisCaptcha == null) {
        return false;
    } else {
        return redisCaptcha.equals(captcha);
    }
}

15.Redis和MySQL双写一致性

在插入商品和修改商品库存时，需要同时在Redis中写入库存，这时就要保证这两个操作的原子性；但是一个存redis一个存mysql不能通过事务达到一致性，

16.减库存和生成订单最终一致

RabbitMQ 实现分布式事务

消息不丢失

发布确认
//发布确认  confirm-callback  (单个确认)
rabbitTemplate.setConfirmCallback(new RabbitTemplate.ConfirmCallback() {
    @Override
    public void confirm(CorrelationData correlationData, boolean b, String s) {
    //未接收到,重新发送
    if (!b) {
        RepublishMessageRecoverer recoverer = new RepublishMessageRecoverer(rabbitTemplate, "secKill_exchange", "");
    }
  }
});
手动应答

秒杀服务在redis中扣减库存成功后，向MQ发出消息，而消费者也就是商品服务和订单服务使用手动应答的方式，商品服务发sql减库存，订单服务就是生成订单，在自己执行完业务且没有错误后，才会通知MQ删除这条消息，并且各个服务之间不影响，各服务只会消费自己队列中的消息；

持久化
  1. 交换机持久化：在上游服务配置声明交换机时的参数
    在这里插入图片描述
  2. 队列持久化：在下游服务接收消息，在声明队列时durable参数设置
    在这里插入图片描述
  3. 消息持久化？ 这个不用配置；因为底层MessageProperties的持久化策略默认是MessageDeliveryMode.PERSISTENT，初始化时默认消息时持久化的
防止消息被重复消费

生产者端幂等

mq收到了消息，但是因为网络没有给生产者应答，导致生产者重复发送消息

对每条消息，MQ系统内部必须生成一个全局唯一的inner-msg-id，作为去重和幂等的依据

消费者端幂等

当前消息被处理完成，没有给mq应答，网络原因或宕机了；
消息就会被重新发送，导致消息被重复消费。

发送消息的时候就用uuid生成订单id，以此来做唯一标识，消费消息前先setIfAbsent()也就是set if not exist，成功了就消费，失败了证明是重复消息，不消费

设计一个秒杀系统之分布式事务
felix
11-04 652
什么是分布式事务？ 如果概念都了解，请移步 分布式事务的几种模式实现 分布式事务时指会涉及多个数据库（服务）的事务，其实就是对同一数据库事务的概念扩大到对多个数据库（服务）的事务。 目的是为了保证分布式系统中的数据一致性。 分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事务的决定产生统一的结果（全部提交或全部回滚）。 分布式事务背景 数据库事务需要满足 ACID（原子性、一致性、隔离性、持久性）四个特性。 原子性（Atomicity）指事务作为整体来执行，要么全部执行
从构建分布式秒杀系统聊聊限流特技
weixin_34130269的博客
06-10 645
前言 俗话说的好，冰冻三尺非一日之寒，滴水穿石非一日之功，罗马也不是一天就建成的。两周前秒杀案例初步成型，分享到了中国最大的同 性友网站-码云。同时也收到了不少小伙伴的建议和投诉。我从不认为分布式、集群、秒杀这些就应该是大厂的专利，在互联网的今天无论什么时候都要时刻武装自己，只有这样，也许你的春天就在明天。 在开发秒杀系统案例的过程中，前面主要分享了队列、缓存、锁和分布式锁以及静态化等等。缓存...
设计秒杀系统（高并发的分布式系统）
最新发布
qq_40453972的博客
03-27 1676
针对紧急上线的商品秒杀需求，我将采用分阶段实现、优先保障核心功能的方案，在确保高并发安全性的前提下快速交付。- 数据库：开启MySQL批量提交（innodb_flush_log_at_trx_commit=2）- 流量突增处理：预先准备Nginx静态降级页面（秒杀页自动跳转到维护公告）- JVM：预设秒杀专用线程池（核心线程数=CPU*2，队列容量=0）- 网络：SLB配置TCP快速打开（tcp_fastopen=3）- 第三阶段（上线后2周）：引入分布式锁优化热点库存。- 按钮防抖（点击后禁用3秒）
分布式架构的秒杀系统设计与实现
weixin_45596022的博客
01-23 503
记录一下自己毕业设计作品的流程-基于分布式微服务架构的秒杀系统 内存状态位：concurrentHashMap 使用分布式锁的原因：防止秒缓存击穿 异步多线程：同时去多个微服务查数据 令牌桶限流：使用谷歌提供的api MD5防止盗链，隐藏真正的秒杀接口 库存list：skuid=1，skunum=100，rediskey-prefix-skuid-rediskey-suffix 1 1 1 1 1 1… 死信队列：基于死信队列构建定时任务，保证消息不被重复消费，保证消息不丢失。 ​ ...
分布式秒杀系统的设计
蹊源的奇思妙想的博客
02-02 3468
不知道你在面试的过程中有没有被问到如何设计一个分布式秒杀系统?本篇博客根据大神们的梳理的体系并结合自己实际的项目经验，大致描述我们在设计分布式秒杀系统需要关注的核心内容——分布式锁、分布式限流、消息队列等等，希望可以帮助同学们可以在面试中更加从容地回答这个问题。
分布式高并发设计案例 之秒杀系统设计
Coder_Boy_的博客
12-23 3102
秒杀系统设计 【第一版设计】 1、前端页层面：防重复提交控制 1)页面秒杀按钮置灰 2)页面防重复提交 2、应用层面 1)令牌机制，通过Redis分配令牌，只有拿到令牌的用户才可去访问数据库 2)同一个用户需设置时间间隔，过时间间隔才可再次提交 3、DB层面 1)防止超卖：数据库乐观锁 【第二版设计】 0、【过滤合法请求】对请求参数做安全校验和接口签名验证 1、【请求分发过滤】请求后端接口前->引入Nginx做负载均衡，分..
分布式秒杀系统构建指南：SpringBoot、Zookeeper与Dubbo的融合
本资源集合《基于SpringBoot+Zookeeper+Dubbo打造分布式高并发商品秒杀系统.zip》详细介绍了如何结合SpringBoot框架、Zookeeper分布式协调服务和Dubbo高性能RPC框架来构建这样的系统。 首先，SpringBoot作为基础...
Java分布式秒杀系统源码.zip
05-19
Java分布式秒杀系统源码，从0到1构建分布式秒杀系统，用户规模可大可小，几百或者上千人的活动单体架构足以可以应付，简单的加锁、进程内队列就可以轻松搞定。一旦上升到百万、千万级别的规模可以考虑分布式集群来...
分布式秒杀系统
07-05
分布式秒杀系统是一种在高并发环境下处理大量用户请求的技术，常用于电商平台的限时抢购活动。这个系统基于一系列先进的IT技术构建，包括JDK 1.7、Maven、Mysql、Eclipse、SpringBoot 1.5.10、Zookeeper 3.4.6、...
spring boot分布式秒杀系统
04-08
在构建一个基于Spring Boot的分布式秒杀系统时，我们需要考虑一系列关键技术和策略，以确保系统的稳定性和高性能。本文将深入探讨这些技术要点，包括系统架构、分流、限流、缓存以及异步处理。 首先，Spring Boot是...
spring-boot-seckill分布式秒杀系统 v1.0/java秒杀系统源码+安装说明
08-08
spring-boot-seckill分布式秒杀系统是一个用SpringBoot开发的从0到1构建的分布式秒杀系统，项目案例基本成型，逐步完善中。 开发环境： JDK1.8、Maven、Mysql、IntelliJ IDEA、SpringBoot1.5.10、zookeeper3.4.6、...
基于redis分布式锁实现“秒杀”
03-01
从业务场景出发，从抽象到实现阐述了如何利用redis实现分布式锁，完成简单的秒杀功能，也记录了笔者思考的过程，希望能给阅读到本篇文章的人一些启发。
秒杀系统架构
极客神殿
04-18 5123
一、秒杀业务为什么难做1）im系统，例如qq或者微博，每个人都读自己的数据（好友列表、群列表、个人信息）；2）微博系统，每个人读你关注的人的数据，一个人读多个人的数据；3）秒杀系统，库存只有一份，所有人会在集中的时间读和写这些数据，多个人读一个数据。例如：小米手机每周二的秒杀，可能手机只有1万部，但瞬时进入的流量可能是几百几千万。12306抢票，票是有限的，库存一份，瞬时流量非常多，都读相同的库存。
从0到1构建分布式秒杀系统，脱离案例讲架构都是耍流氓
baidu_33403616的博客
10-22 232
嗯嗯，好长时间不更新博客了，感觉整个人都颓废了哈哈，不过呢我还是蛮怀恋这种指尖在键盘上敲打的感觉的。最近闲来无事，就在码云上看看有没有什么比较小的开源项目来学习学习（内容太多看不下去= =看了半天看到这么一个项目） 瞬间被吸引了，感觉挺牛般的，fork,star,download 三连击，下载，部署环境搞了老半天终于搞好了，然后运行测试美滋滋。 以上都是废话= =，言归正传。我今天主要就聊...
分布式秒杀系统一
谋莽台的博客
05-10 385
分布式秒杀系统一 文章目录分布式秒杀系统一分布式秒杀系统的难点架构图路由网关的作用（Zuul/GateWay）如果路由网关崩了怎么办那为什么还要nginx如果LVS也崩了主机和备机IP地址不同，如何在主机崩了情况下访问备机ip，并且备机如何知道主机崩了注册中心的作用（Eureka，Zookeeper，Nacos）A服务如何调用B服务为什么不直接调用数据库设计工程结构为什么要单独创建一个微服务工程继承于父工程配置环境多环境部署 分布式秒杀系统的难点 并发量大 线程安全的问题（防止库存超卖）：如果单纯加锁会导
秒杀系统架构优化思路
deng1228的博客
09-12 108
　　一、秒杀业务为什么难做 　　1）、im系统，例如qq或者微博，每个人都读自己的数据（好友列表、群列表、个人信息）； 　　2）、微博系统，每个人读你关注人的数据，一个人多多个人的数据； 　　3）、秒杀系统，库存只有一份，所有人会在集中的时间读和写这些数据，多个人读一个数据； 　　例如：小米手机每周二的秒杀，可能手机只有1万部，但瞬时进入的流量可能是几百几千万。 　　例如：12...
分布式秒杀 - 实战
架构师尼恩
01-05 2506
疯狂创客圈 Java 高并发【 亿级流量聊天室实战】实战系列之15 【博客园总入口 】 前言 疯狂创客圈（笔者尼恩创建的高并发研习社群）Springcloud 高并发系列文章，将为大家介绍三个版本的 高并发秒杀： 一、版本1 ：springcloud + zookeeper 秒杀 二、版本2 ：springcloud + redis 分布式锁秒杀 三、版本3 ：springcloud + Ngi...
java 使用 SpringBoot + Redis 分布式锁秒杀！
tumu6889的博客
06-23 569
Redis 分布式秒杀
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

EnndmeRedis

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值