- 博客(35)
- 收藏
- 关注
RSS订阅原创 消息治理，到底需要治理哪些内容？
大家好，我是【架构摆渡人】，一只十年的程序猿。这是消息队列的第六篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。不知道大家发现没有，虽然市面上已经有很多优秀的开源消息队列了，但是一些公司还是热衷于自研。并不是说开源的不好，而是开源的产品要考虑的是很多通用的场景，而公司内部可以更加精细化的考虑公司内部的场景，结合业务的特点来研发出更适合企业的框架。无论是微服务，还是消息队列，都会涉及到治理。那么消息我们到底需要进行哪些治理呢？强大的监控体系服务端监控MQ本身
2022-05-29 10:01:26
174
原创 消息队列，推拉模式的区别在哪？
大家好，我是【架构摆渡人】，一只十年的程序猿。这是消息队列的第五篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。在学习消息队列的时候，大家都有一个共同的问题，那就是消息到底是服务端推送给客户端还是客户端主动去服务端拉取然后进行消费。今天这篇文章就来解答大家的这个的疑问。推模式首先我们来解决下什么是推模式，顾名思义，推模式就是我推给你。在MQ中也就是Broker收到消息后主动推送给Consumer的操作，叫做推模式。推模式的实现是客户端会与服务端（Broker
2022-05-17 20:14:46
1324
原创 如何降低复杂度，用数据库做消息队列的存储？
大家好，我是【架构摆渡人】，一只十年的程序猿。这是消息队列的第一篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。今天跟大家聊聊如何用数据库来做消息的存储，这样就可以将消息队列的整体复杂度进行降低，如果后续你们需要自己造更贴近公司业务的轮子，我觉得可以用数据库来存储。容量设计假设你们的业务消息量每天是10亿条，数据存储最近7天的量，也就是70亿条。我们以单表2000W条数据作为上限，1个库放10张表，那么总共需要40个库来承载这些数据量。当然这40个库可以不用
2022-05-16 22:19:02
344
原创 推荐一款数据mock框架，无需任何依赖，贼牛逼
fox-mock 是基于Java Agent实现的自测，联调Mock利器。能解决你的这些问题：开发过程中，依赖了下游多个接口，想跑个单测都必须得等下游把服务部署好联调过程中，下游某个接口出问题，阻塞了整个流程其他需要Mock方法返回值的场景最大的优点：无侵入式的Mock解决方案，支持应用启动前挂载和应用启动后attach挂载。支持本地文件mock支持对接配置中心管理mock数据Github地址：https://github.com/yinjihuan/fox-mock使用视频讲解:
2022-05-08 10:39:30
538
原创 多维度分片需求，如何解决查询问题？
大家好，我是【架构摆渡人】，一只十年的程序猿。这是分库分表系列的第一篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。其实这个系列有录过视频给大家学习，但很多读者反馈说看视频太慢了。也不好沉淀为文档资料，希望能有一系列文字版本的讲解，要用的时候可以快速浏览关键的知识点。那么它就来了，我再花点时间写成几篇连续的文章供大家学习。需求背景单库单表的时候，我们在实现业务需求的时候，是不会考虑说哪些字段不能用于查询，只要表中有的字段就可以用它来做条件查询。当分库分表后，
2022-05-04 19:45:24
434
原创 如何设计一个牛逼的消息队列？
大家好，我是【架构摆渡人】，一只十年的程序猿。这是消息队列的第一篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。通过前面文章的学习，我们对消息队列的作用以及目前主流的一些消息队列中间件有了更深刻的了解。但是那些优秀的中间件都是别人写出来的，如果你在面试的时候，面试官问你：**如果让你去设计一个消息队列，你打算怎么做？**如果你对消息队列了解的不彻底，那么很有可能被这个问题问懵掉，最后支支吾吾的说不知道。服务端我们从日常使用消息队列来入手，看设计一个消息队列到底
2022-05-01 20:11:19
845
原创 主流消息队列有哪些？
大家好，我是【架构摆渡人】，一只十年的程序猿。这是消息队列的第一篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。ActiveMQActiveMQ是一个很老的消息队列了，我也只是在很老的一些系统里面见过它。无论是性能还是功能方面，确实没有跟上时代的节奏，社区也不活跃。大家可以去看看，在Github上的关注也就2K的数量。对Java开发者来说，它最大的有点就是用Java开发的，阅读源码比较方便，其他就没啥优点了，所以也不建议大家现在用ActiveMQ来实现业务。
2022-04-23 16:22:13
3125
1
原创 消息队列为何如此重要？
大家好，我是【架构摆渡人】，一只十年的程序猿。这是消息队列的第一篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。不知道大家平时是否有使用过Queue相关的类，比如ArrayBlockingQueue，DelayQueue等队列。如果你说你平时写业务代码都没用过这些，其实也很正常，但是你其实间接都使用过。比如线程池，这个大家肯定都用过，那么你想象下，如果你一直往线程池里面丢任务，当任务丢不进去之后会触发拒绝策略。但是前期的这个任务都是在排队等待执行，那这些任务暂存
2022-04-17 10:03:23
309
原创 分库分表实现方式Client和Proxy，性能和维护性该怎么选？
大家好，我是【架构摆渡人】，一只十年的程序猿。这是分库分表系列的第一篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。其实这个系列有录过视频给大家学习，但很多读者反馈说看视频太慢了。也不好沉淀为文档资料，希望能有一系列文字版本的讲解，要用的时候可以快速浏览关键的知识点。那么它就来了，我再花点时间写成几篇连续的文章供大家学习。分库分表的手段手动路由如果没有复杂的操作，手动路由相对来说是简单的方式。比如你的操作只根据分片键操作，那么通过分片键你可以计算出这条数据的
2022-04-04 14:47:09
985
原创 分库分表系列: 到底该怎么拆分？
大家好，我是【架构摆渡人】，一只十年的程序猿。这是分库分表系列的第一篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。其实这个系列有录过视频给大家学习，但很多读者反馈说看视频太慢了。也不好沉淀为文档资料，希望能有一系列文字版本的讲解，要用的时候可以快速浏览关键的知识点。那么它就来了，我再花点时间写成几篇连续的文章供大家学习。在实际业务实践过程中，垂直拆分和水平拆分都必须用才行。拆分之前我们先来了解有哪些常用的拆分方式。分表算法这么多，我该怎么选？时间按时间拆
2022-03-26 20:48:55
3005
原创 分库分表系列：分库分表的前世今生
大家好，我是【架构摆渡人】，一只十年的程序猿。这是分库分表系列的第一篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。其实这个系列有录过视频给大家学习，但很多读者反馈说看视频太慢了。也不好沉淀为文档资料，希望能有一系列文字版本的讲解，要用的时候可以快速浏览关键的知识点。那么它就来了，我再花点时间写成几篇连续的文章供大家学习。什么是分库分表？一般，一个应用刚开始开发的时候，都是连接一个数据库。因为这个时候业务并不复杂，处于起步阶段。当然重构类的除外，重构类的是已经
2022-03-19 21:24:12
877
原创 最简单的异常和业务监控方案
大家好，我是【架构摆渡人】，一只十年的程序猿。这是实践经验系列的第十二篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。监控三板斧在监控领域，最常用的三种方式就是Metrics, Tracing，Logging，可以称之为三板斧。Metrics系统度量，通过指标来度量系统是否正常，比如现在主流的Prometheus就是基于指标来构建监控体系。Tracing链路跟踪，用户的一次请求将贯穿这个链路，想要进行优化或者知道请求在哪个环节出问题，链路跟踪必不可少。
2022-03-12 20:13:48
1168
原创 听说：分布式ID不能全局递增？
大家好，我是【架构摆渡人】，一只十年的程序猿。这是实践经验系列的第十一篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。前面有篇文章我们讲到用时间来代替自增ID进行分页排序，原因是因为接入了分布式ID，但是分布式ID不能够保证有序，只能保证全局唯一。那么今天我们一起来探讨下，究竟能不能实现有序的分布式ID呢？分布式ID的实现方式号段模式号段模式是目前用的比较多的实现分布式ID的方式，号段模式通过预先获取一段范围，然后全部在内存中进行ID的分发，性能极高。采
2022-03-06 14:30:49
735
原创 Redis实现访问次数限流，这有难点吗？
大家好，我是【架构摆渡人】，一只十年的程序猿，这是流量治理系列的第11篇原创文章，如果有收获，还请分享给更多的朋友。假设我们要做一个业务需求，这个需求就是限制用户的访问频次。比如1分钟内只能访问20次，10分钟内只能访问200次。因为是用户维度的场景，性能肯定是要首先考虑，那么适合这个场景的非Redis莫属。最简单的实现，莫过于只是用incr进行计数操作，于是有了下面的代码：long count = redisTemplate.opsForValue().increment("user:1:60");
2022-02-23 22:52:15
530
原创 深度分页，我都是这么玩的
大家好，我是架构摆渡人。这是实践经验系列的第十一篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。分页查询，无论是在B端的系统，还是C端的应用，都有着广泛的应用。只不过是应用方式和对性能的要求不一样而已。在B端的系统中一般都是一个列表，下面有一个分页的组件，可以选择第几页的数据，可以进行上下分页，这种就是最常见的分页方式，对应到数据库中我们常实现的方式就是limit 0,10这种。在C端的应用中，也有分页查询的场景，但是对应性能要求比较高，我们都知道传统limi
2022-02-20 10:50:54
309
原创 限流监控，通常需要关注哪些指标？
大家好，我是架构摆渡人。这是流量治理系列的第8篇文章，如果有收获，还请分享给更多的朋友。限流是一种自我保护的方式，虽然保护了系统的稳定性，但是对用户体验是有影响的，那么在触发的时候我们能不能够知道影响范围有多大呢？这就需要有完整的监控体系来帮助我们去了解限流的一些信息，今天跟大家聊一聊需要经常关注的指标。如果你要构建限流的监控大盘，那么这些指标或许对你有参考意义。有没有触发流控？首先我们要关注的重点就是到底有没有触发限流，一旦触发了限流，也就意味着流量的突然上涨，是正常的活动导致，还是被爬虫了，还是
2022-02-12 21:52:26
529
原创 流量治理神器-Sentinel 究竟是怎么做到让业务方接入简单？
大家好，我是架构摆渡人，这是流量治理系列的第10篇原创文章，如果有收获，还请分享给更多的朋友。做业务开发，需要考虑业务的扩展性。做基础框架开发，需要考虑如何让业务方接入，使用简单，尽量不要耦合在业务代码中。Sentinel里面是如何做到让业务方接入简单，使用方便的呢？这篇文章就来剖析下Sentinel的那些适配是如何实现的。基本使用基本使用可以直接用SphU类对资源进行保护，使用方式如下：public static void main(String[] args) { // 配置规则.
2022-02-12 21:50:31
238
原创 在线进行分库分表中间件的平滑升级，正所谓艺高人胆大
大家好，我是架构摆渡人。这是实践经验系列的第十篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。故事还要从N年前说起，那时业务发展的比较快，数据每天增长比较多。很快就经常出现慢SQL各种问题，拆库迫在眉睫。为了快速上线，直接在应用中进行拆分规则的处理，也就是将分库分表的逻辑在客户端进行处理，这样的方式简单，性能也不错。过了一年多，技术部加了好多人，细分的团队也更多了。老项目用的自研的客户端分库分表方式，有一些新团队内部用的开源的框架。随着技术部规模越来越大，我们也
2022-01-27 22:07:32
2346
原创 Mybatis插件，能做的事情真的很多
大家好，我是架构摆渡人。这是实践经验系列的第九篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。Mybatis是我们经常用的一款操作数据库的框架，它的插件机制设计的非常好，能够在很多需求场景下派上用场。如果你还没用过Mybatis的插件（Mybatis 插件实际是一种拦截器），那么需要仔细阅读这篇文章。SQL监控埋点说句大实话，大部分性能问题都发生在存储层。当然对于优化我们需要有足够的样本，这些样本也就是慢SQL。数据库本身就有慢SQL的日志，但不方便我们跟具体
2022-01-22 14:20:03
753
原创 服务优雅下线，没你想的那么简单？
大家好，我是架构摆渡人。这是实践经验系列的第八篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。服务部署，是一个避免不了的问题。按正常迭代的速度一般两周会发一个版本，此时就需要部署新的代码。发布方式，我相信主流的都是用滚动发布，因为这样的成本是最低的，机器数量是固定的，一台台机器轮流发布。但是我们总会在发布过程中碰到一些报错信息，那是因为请求还没结束，某些组件已经强制停止了，比如我们的数据源，比如异步任务还没处理完。那么如何解决这个问题呢？那就是服务优雅下线，估
2022-01-16 11:11:11
569
原创 ON UPDATE CURRENT_TIMESTAMP请慎用
大家好，我是架构摆渡人。这是实践经验系列的第七篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。今天给大家分享一个容易忽略的问题，正是因为容易忽略，所以才要重视。我们的业务表中有两个字段是必不可少的，分别是创建时间和修改时间，这样就知道数据是什么时候创建的，最后一次的修改时间是什么时候。就是经常会在修改时间上看到这个语句ON UPDATE CURRENT_TIMESTAMP，SQL语句如下：`update_time` timestamp NULL DEFAUL
2022-01-08 21:19:33
2385
原创 每次上线都要加字段，走变更，如何破局？
大家好，我是架构摆渡人。这是实践经验系列的第六篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。不知道大家有没有遇到过类似的问题，每次新需求上线，或多或少都会有表结构的变更。主要就是需要新增字段来存储某些特有需求的数据，听起来其实很正常，新需求嘛，加字段，加表都是正常的，如果是传统行业也没啥太大问题。但是对于互联网To C的应用来说，流量高，数据量大，每次对表进行DDL操作耗时都会非常长，主要是数据量太大了，而且都是分库分表的，几千张表都很正常。用过MongoDB
2022-01-03 21:27:34
635
原创 核心接口隔离，要做哪些事情？
大家好，我是架构摆渡人。这是实践经验系列的第五篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。今天跟大家聊聊隔离这个话题，对于高流量的业务场景，以电商业务举例，一定要做好核心接口的隔离，否则真的就是牵一发而动全身。以前的工作中有遇到过因为一个卖家的后台查询，产生了慢SQL，导致单量直线下跌，用户无法下单了，都是系统异常，超时报错。要解决好这些问题，隔壁必须要做，虽然成本比较大，但是带来的收益是你想象不到的稳定。具体怎么做，有哪些步骤，各位看官请继续阅读下去。
2021-12-25 14:17:29
1175
原创 缓存Bigkey坚决不要用，拆分是王道
大家好，我是架构摆渡人。这是实践经验系列的第四篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。背景介绍在高并发的业务场景中，缓存是必须要上的，用来扛高并发。在某个业务场景中，增加了对一个配置信息的缓存，最开始是直接读取DB的，为了性能考虑在前面加了一层缓存。加完后很长一段时间也没问题，DB的压力也减小了很多。不幸的是在某天的一个时间点内，流量增加了好几倍，RT直线上升，接口各种超时，就这样，一个线上故障诞生了。整个过程持续了1分钟左右，监控告警稍微有点延迟，
2021-12-25 14:06:56
898
原创 binlog真的是银弹吗？有些时候也让人头疼
大家好，我是架构摆渡人。这是实践经验系列的第三篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。binlog 用于记录用户对数据库操作的SQL语句信息，同时主从复制也是依靠binlog来实现的，由此可见binlog的重要性。在业务中的使用场景binlog除了数据库本身使用它实现一些功能，在业务中我们也会经常依靠binlog实现各种需求。数据异构基于binlog的数据异构是用的最多的一个场景，可以通过监听binlog将数据异构成其他维度，方便查询。比如多表聚
2021-12-07 19:55:42
245
原创 稳定性保障，如何慢慢放量灰度
大家好，我是架构摆渡人。这是实践经验系列的第二篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。上篇文章给大家分享了开关的应用技巧，通过开关去保证上线时的稳定性。但是开关还是属于一刀切的那种，如果流量特别大的情况下，影响面还是挺大的，所以今天就给大家再补充一种方式，灰度放量。举个例子说明下：比如你在重构订单详情接口，这个接口之前是在A服务里面，由于后续服务拆分更精细化，新拆了一个服务，需要将这个接口迁移到新服务里面去。此时最简单的做法就是把代码复制过去，然后让客户
2021-12-05 16:08:11
308
原创 上线稳定性如何保证？开关编程很有用
大家好，我是架构摆渡人。这是实践经验系列的第一篇文章，这个系列会给大家分享很多在实际工作中有用的经验，如果有收获，还请分享给更多的朋友。在日常工作中，无论是一周一个迭代，还是两周一个迭代，都避免不了上线的环节。唯一的区别就是上线的频次不同而已。那么我们如何保证在这么高频次的发版里面同时保证稳定性呢？答案就是开关编程，所谓的开关编程其实就是加个if判断，但是可以动态去调整if里面的值，能够随时控制逻辑的走向。开关需要自己编写，自己控制，动态调整值则可以借助于配置中心，改变后实时刷新。案例一：旧功能里面加
2021-11-27 16:34:04
96
原创 流量治理最大的痛点-资源利用率上不去
大家好，我是架构摆渡人，这是流量治理系列的第9篇原创文章，如果有收获，还请分享给更多的朋友。曾经有人问过我，限流有痛点吗？我当时的回答是：限流阀值不太好评估以及限流降低了用户的体验，这是我认为的痛点。限流阀值到底怎么评估还是得有压测的动作，特别是现在电商平台，在大促前都会进行全链路压测，将问题暴露出来，看能承受多少流量的请求。然后再根据业务预期，就知道要不要扩容，以及流控的指标了，说难也不难，就是需要多种手段进行佐证。降低用户体验这个是限流必须经历的，用户正在下单，然后收到的提示就是服务器当前太拥挤，
2021-11-13 18:19:30
208
原创 网关限流了，躲在后面的服务就能高枕无忧啦？
大家好，我是架构摆渡人。这是流量治理系列的第7篇文章，如果有收获，还请分享给更多的人，谢谢大家。今天想跟大家聊一个比较有意思的话题，就是：网关限流了，服务本身就能高枕无忧了吗？我想大部分公司的架构都是下面这样子的，网关在最前面，充当了守门员的工作。请求想要进来，必须经过网关，所以在网关层面做流控是最合适的，没有之一。如果我们认为，只要网关把入口的流量控制好了，下游的服务就不用瞎操心了，直接躺平即可。这种想法本身没错，可是经过大量的实践，往往故事的结局却不是你想象的那么美好。首先，如果你作为某一个服
2021-10-25 23:01:21
110
原创 开放平台的限流通常都是怎么实现的？
开放平台，我相信大家并不陌生。当需要把一个产品本身的一些功能开放出去，可以让三方开发者接入和使用，这就是开放平台做的事情。为什么我们能用微信登录很多其他的应用，这就是因为这些应用通过接入微信开放平台提供的能力实现了授权登录。开放平台流控需求分析对于开放平台来说，有一个功能是必须要有的，那就是API的流控。对于每一个接入开放平台的应用，都会分配一个Appkey，这个Appkey下面会关联你申请了哪些API。然后接入的API有些是不限量，可以一直调用。有些是需要申请调用包，比如一天10万次的调用量。
2021-10-23 19:00:20
622
1
原创 流量治理神器-Sentinel的限流模式，选单机还是集群？
大家好，架构摆渡人。这是我的第5篇原创文章，还请多多支持。上篇文章给大家推荐了一些限流的框架，如果说硬要我推荐一款，我会推荐Sentinel，Sentinel的限流模式分为两种，分别是单机模式和集群模式。今天我们就来学习下这两种模式的区别和使用场景。单机流控单机流控就是流控的效果只针对服务的一个实例，比如你的服务部署了三个实例分别在三台机器上。请求访问到了A实例的时候，如果触发了流控，那么只会限制A实例后面的请求，不会影响其他实例上的请求。比如你单身的时候，每月的工资都花个精光。影响的只是你自己，
2021-10-17 23:40:03
561
原创 这么多开源的限流框架，该宠幸谁呢？
大家好，架构摆渡人。这是我的第4篇原创文章，还请多多支持。限流一直就是一个比较热门而又老旧的话题，但是作为应对高并发的手段之一，限流的热度一直都在。前面我们大概的介绍了限流的背景，主流的限流算法，以及到底是选择自研还是选择开源的框架来实现限流功能，相关文章可以翻阅历史记录进行查看。自研这条路没有一定的实力真的不好走，大多数的选择估计都是开源。那么我今天就介绍几款用的比较多的限流框架给大家。GuavaGuava里自带了Ratelimiter用于限流，该类基于令牌桶算法实现流量限制功能。接入呢也比较简
2021-09-28 23:27:28
505
2
原创 流量治理选开源还是自研，有点小纠结
当你看到这篇文章时，恭喜你，已经了解了为什么要做流量治理以及目前主流的限流算法和原理。没看过这个系列前两篇文章的可以回头翻翻历史文章。当你决定要做流量治理这件事时，必定会遇到一个比较纠结的问题，就是用开源还是自研呢？今天我们从下面几个方面来分析下，什么时候该自研，什么时候该直接用开源的成果。公司规模规模比较大的公司，业务稳定。有成本和能力进行自研，主要目标是系统的稳定性。这种公司一般都会选择自研，或者在开源的基础上进行深度定制开发来满足内部的需求。当然并不是规模大就一定会自研，我讲的只是这个规模的
2021-09-13 21:26:56
8156
原创 亿级流量治理系列：常用的限流算法有哪些？
上篇文章《为什么大公司都要做流量治理？》跟大家聊了下做流量治理的真正目的是什么。如果你要开发一个流量治理的平台或者一个限流的框架，那么必不可少的就是要选择一种合适的限流算法。本篇文章就跟大家聊聊目前常用的限流算法有哪些。计数器计数器是最简单，最直接明了的限流算法。说白了就是进行数字累加操作，也就是count++ 这你总能看懂吧！单机限流可以直接使用LongAdder或者AtomicLong这些原子类进行计数操作即可。用Semaphore也可以，Semaphore内部本身就是计数器的方式实现。集群限流
2021-09-06 22:45:34
758
原创 亿级流量治理系列：为什么大公司都要做流量治理？
流量治理定义在高并发的互联网业务场景下，限流和熔断、降级经常被提起和应用。其中限流就属于流量治理的一部分。当然流量治理除了限流之外，还有其他的一些对流量进行管控的方式，比如：控制流量的分发，流量的监控，流量的预测等。流量治理的目的为系统购买一份保险做流量治理，其实也就是相当于给系统买了一份保险。既然是保险那么就不是时时刻刻能用的到，只有在需要的时候才可以使用。以电商业务场景来举例，平日的流量对于系统来说都能扛的住。就怕搞活动，大促这些时间节点下，流量暴增，一下就把系统击垮了。马上重启，一波新流量来
2021-08-30 22:49:55
159
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人