Mobabel

Just One Pure ITer

Category: Java Architecture

[转]谈谈服务雪崩、降级与熔断 0

High Concurrency, Circuit Breaker, Rate Limit, Load Balance,etc...

[转]谈谈服务雪崩、降级与熔断

首先，之所以谈这个话题呢，是发现现在很多人对微服务的设计缺乏认识，所以写一篇扫盲文。当然，考虑到目前大多微服务的文章都是口水文，烟哥争取将实现方式讲透，点清楚，让大家有所收获！ OK，我要先说明一下，我有很长一段时间将服务降级和服务熔断混在一起，认为是一回事！

[转]分布式缓存中的一致性哈希算法 0

Distributed Global ID Generator

[转]分布式缓存中的一致性哈希算法

一致性哈希算法在分布式缓存领域的 MemCached，负载均衡领域的 Nginx 以及各类 RPC 框架中都有广泛的应用 它主要是为了解决传统哈希函数添加哈希表槽位数后要将关键字重新映射的问题。 本文会介绍一致性哈希算法的原理及其实现，并给出其不同哈希函数实现的性能数据对比，探讨Redis 集群的数据分片实现等，文末会给出实现的具体 github 地址。

[转]蚂蚁金服 30 万级测试用例的核心应用如何分钟级运行？ 0

CI & Automation Test

[转]蚂蚁金服 30 万级测试用例的核心应用如何分钟级运行？

1. 背景与挑战——又稳又快 互联网行业的最主要属性是快，一方面是量的快速增长；另一方面是业务场景的多样化变更。每年的交易量都增长得非常快速，同时业务也快速丰富起来，之前可能只有线上电商担保交易，现在新增了许多金融属性的业务如花呗、借呗、相互保，甚至还有跨境支付。同时，蚂蚁金服具备的金融属性，要确保监管合规和资金安全，需要把稳放到首位，我们需要在这个稳的基础上去快速创新以满足市场的快速变化。也就是说要“又稳又快”。 把又稳又快深入到软件开发，「稳」要求软件质量可靠；「快」体现在研发队伍快速扩张和代码量的快速增长。在这种背景下，对于 CI（持续集成）的研究和改造成为保障软件质量可靠又快速交付的有效手段。

[转]分库分表无限扩容 0

Database Partitioning&Scaling

[转]分库分表无限扩容

1. 正常情况下的服务演化之路 让我们从最初开始。 1-1. 1、单体应用 每个创业公司基本都是从类似 SSM 和 SSH 这种架构起来的，没什么好讲的，基本每个程序员都经历过。 1-2. 2、RPC 应用 当业务越来越大，我们需要对服务进行水平扩容，扩容很简单，只要保证服务是无状态的就可以了，如下图： 当业务又越来越大，我们的服务关系错综复杂，同时，有很多服务访问都是不需要连接 DB 的，只需要连接缓存即可，那么就可以做成分离的，减少 DB 宝贵的连接。如下图： 我相信大部分公司都是在这个阶段。Dubbo 就是为了解决这个问题而生的。 1-3. 3、分库分表 如果你的公司产品很受欢迎，业务继续高速发展，数据越来越多，SQL 操作越来越慢，那么数据库就会成为瓶颈，那么你肯定会想到分库分表，不论通过 ID hash 或者 range 的方式都可以。如下图： 这下应该没问题了吧。任凭你用户再多，并发再高，我只要无限扩容数据库，无限扩容应用，就可以了。 这也是本文的标题，分库分表就能解决无限扩容吗？ 实际上，像上面的架构，并不能解决。 其实，这个问题和...

[转]跨库分页的几种常见方案 0

Database Partitioning&Scaling

[转]跨库分页的几种常见方案

为什么需要研究跨库分页？ 互联网很多业务都有分页拉取数据的需求，例如： （1）微信消息过多时，拉取第N页消息； （2）京东下单过多时，拉取第N页订单； （3）浏览58同城，查看第N页帖子；

[转]1万属性，100亿数据，每秒10万吞吐，架构如何设计？ 0

Database Theory & Solution

[转]1万属性，100亿数据，每秒10万吞吐，架构如何设计？

有一类业务场景，没有固定的schema存储，却有着海量的数据行数，架构上如何来实现这类业务的存储与检索呢？58最核心的数据“帖子”的架构实现技术细节，今天和大家聊一聊。 1. 一、背景描述及业务介绍 什么是58最核心的数据？ 58是一个信息平台，有很多垂直品类：招聘、房产、二手物品、二手车、黄页等等，每个品类又有很多子品类，不管哪个品类，最核心的数据都是“帖子信息”。 画外音：像不像一个大论坛？