这样的Dubbo + Redis千万级分布式超高并发秒杀案例,有点厉害!
Posted java版web项目
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了这样的Dubbo + Redis千万级分布式超高并发秒杀案例,有点厉害!相关的知识,希望对你有一定的参考价值。
超高并发场景下,你能想到几种可靠的解决方案?
流量优化:防盗链处理;
前端优化:减少 HTTP 请求,合并脚本,使用异步请求,启用浏览器缓存和文件压缩,CDN 加速,图片服务器用起来;
服务端优化:页面静态化,并发处理,服务降级,限流,消息队列用起来;
数据库优化:数据库缓存,分库分表,分区操作,读写分离,负载均衡;
Web 服务器优化:负载均衡,nginx 反向代理,7,4层 LVS 软件等。
那咱们,就先聊聊「服务端」的高并发,如何优化?如何保护好系统?
01
服务端,超级重头戏:Dubbo + Redis
服务端要扛住高并发,先要实现服务器的负载均衡,保证服务消费者能够通过轮询或其他策略,成功调用服务提供者已实现的服务。
Dubbo 自身实现了四种负载均衡策略:随机、轮询、最少活跃调用数和一致性。Dubbo 的负载均衡是基于服务层面的中间件,在阿里也撑起了很多内部业务,它的性能和高效是毋庸置疑的。
大家知道吗?在高并发系统中,有很多方法来保护系统的,比如:缓存、降级、限流等。
降级:主要对一些服务和页面有策略地不处理或换种简单的方式处理,从而释放服务器资源以保证核心服务正常运作或高效运作;(问题1:降级有多少种手法?应该怎么高效降级?)
对于服务降级这个问题,要注意:
1)一定是先降级优先级低的接口,两权相害取其轻,区分核心和非核心服务;
2)如果服务链路整体没有性能特别差的点,比如就是外部流量突然激增,那么就从外到内开始降级;
3)如果某个服务能检测到自身负载上升,那么可以从这个服务自身做降级;
4)业务支持降级策略,放通策略。
比如说,Dubbo 提供了一些服务降级措施,它可以对消费端的调用进行降级,这样服务消费端就避免了再去调用出错的服务提供端,而是使用自定义的返回值直接在本地返回。(问题2:与 Spring Cloud 的熔断机制相比哪个更好?具体原因?)
Dubbo 可以使用使用 mock 来设置本地伪装,提供了 force:return 和 fail:return 两种策略。(贴上一丢丢代码,可以先看看~)
// 获取服务注册中心工厂
RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();
// 根据zk地址,获取具体的zk注册中心的客户端实例
Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://127.0.0.1:2181"));
// 注册降级方案到zk,对test分组1.0.0版本的服务降级。category必须为configurators,override://0.0.0.0/表示该降级策略对所有的服务消费者生效
// dynamic=false表示该数据为持久数据,注册放退出依旧保存在注册中心,application表示只对指定应用生效,否则表示所有应用生效
registry2.register(URL.valueOf(
"override://0.0.0.0/com.test.TestService?category=configurators&dynamic=false&application=myConsumer&mock=force:return+null&group=test&version=1.0.0"
));
上面只围绕降级给大家提了几点,另外缓存、限流怎么实现呢?
这段时间,我们把对Java多线程高并发的深入思考结合「代码」,不断打磨、凝练,熬出了一套新课程(仅9.8 ≈ 1 杯小奶茶)。
不赚钱,交个朋友!
以上是关于这样的Dubbo + Redis千万级分布式超高并发秒杀案例,有点厉害!的主要内容,如果未能解决你的问题,请参考以下文章
阿里二面:千万级亿级数据,如何性能优化? 教科书级 答案来了