亲身经历过高并发后，才发现Dubbo + Redis太牛X了！
Posted 程序员狗哥
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了亲身经历过高并发后，才发现Dubbo + Redis太牛X了！相关的知识，希望对你有一定的参考价值。
超高并发场景下，你能想到几种可靠的解决方案？
流量优化：防盗链处理；
前端优化：减少 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多线程高并发的深入思考结合「代码」，不断打磨、凝练，熬出了一套最新的3天在线专栏课程（仅9.8 ≈ 半杯奶茶）。
12月8-10日，每晚20:00-21:30
不赚钱，交个朋友！
以上是关于亲身经历过高并发后，才发现Dubbo + Redis太牛X了！的主要内容，如果未能解决你的问题，请参考以下文章