Mobabel

Just One Pure ITer

Category: Distributed Architecture

[转]携程200T+规模的Redis容器化实践 0

Redis High Avaliable Scale Architect

[转]携程200T+规模的Redis容器化实践

1. 背景 携程大部分应用是基于 CRedis 客户端通过集群来访问到实际的 Redis 的实例，集群是访问 Redis 的基本单位，多个集群对应一个 Pool，一个 Pool 对应一个 Group，每个 Group 对应一个或多个实例，Key 是通过一致性 hash 散列到每个 Group 上，集群拓扑图如截图所示。 这个图里面我们可以看到集群，Pool，Group 还有里面的实例，这是携程 Redis 一个比较常见的拓扑图，如下图： 2. 为什么要容器化 2-1. 标准化和自动化 Redis 之前是直接部署在物理机上，而 DBA 是根据物理机上设定的 Redis 的版本来选择需要部署的物理机，携程的各个版本的...

[转]Netty学习和进阶策略 0

Netty

[转]Netty学习和进阶策略

1. 背   景 1-1. Netty 框架的特点 Netty 的一个特点就是入门相对比较容易，但是真正掌握并精通是非常困难的，原因有如下几个： 涉及的知识面比较广：Netty 作为一个高性能的 NIO 通信框架，涉及到的知识点包括网络通信、多线程编程、序列化和反序列化、异步和同步编程模型、SSL/TLS 安全、内存池、HTTP、MQTT 等各种协议栈，这些知识点在 Java 语言中本身就是难点和重点，如果对这些基础知识掌握不扎实，是很难真正掌握好 Netty 的。 调试比较困难：因为大量使用异步编程接口，以及消息处理过程中的各种线程切换，相比于传统同步代码，调试难度比较大。 类继承层次比较深，有些代码很晦涩（例如内存池、Reactor 线程模型等），对于初学者而言，通过阅读代码来掌握 Netty 难度还是比较大的。 代码规模庞大：目前，Netty 的代码规模已经非常庞大，特别是协议栈部分，提供了对 HTTP/2、MQTT、WebSocket、SMTP 等多种协议的支持，相关代码非常多。如果学习方式不当，抓不住重点，全量阅读 Netty 源码，既耗时又很难吃透，很容易半途而废。 资料比较零散，缺乏实践相关的案例：网上各种 Netty 的资料非常多，但是以理论讲解为主，Netty 在各行业中的应用、问题定位技巧以及案例实践方面的资料很少，缺乏系统性的实践总结，也是 Netty...

[总]消息顺序性为何这么难？ 0

Distributed Global ID Generator

[总]消息顺序性为何这么难？

很多业务都需要考虑消息投递的顺序性： 单聊消息投递，保证发送方发送顺序与接收方展现顺序一致 群聊消息投递，保证所有接收方展现顺序一致 充值支付消息，保证同一个用户发起的请求在服务端执行序列一致 消息顺序性是分布式系统架构设计中非常难的问题，有什么常见优化实践呢？

[转]Kafka 2.0升级实战！携程的经验有何可借鉴之处 0

Kafka Practice

[转]Kafka 2.0升级实战！携程的经验有何可借鉴之处

早在 2014 年，携程的一些业务部门开始引入 Kafka 作为业务日志的收集处理系统。2015 年，基于 Kafka 的高并发、大数据的特点，携程框架研发部在 Kafka 之上设计了 Hermes Kafka 消息系统，作为大规模的消息场景的统一的中间件。随着业务量的迅速增加，以及具体业务、系统运维上的一些误用，Kafka 现有系统变得不稳定，经历了多次 down 机，故障期间完全不可用，持续时间长达 5 小时以上，恢复缓慢。Kafka 还能用多久？成为一个迫切棘手的问题。问题严重又难以解决，必须做出改变。 本文主要分享携程将 Kafka 从 0.9 升级到 2.0 的实战经验以及基于 Kafka 2.0 的应用实践。这是 InfoQ 特别策划《Kafka 的七年之痒》专题系列文章的第三篇，前两篇文章回顾见 《Kafka 从 0.7...

[转]业务库负载翻了百倍，我做了什么来拯救MySQL架构？ 0

MySQL Master/Slave, R/W Seperation

[转]业务库负载翻了百倍，我做了什么来拯救MySQL架构？

最近有一个业务库的负载比往常高了很多，最直观的印象就是原来的负载最高是100%，现在不是翻了几倍或者指数级增长，而是突然翻了100倍，导致业务后端的数据写入剧增，产生了严重的性能阻塞。 1. 一、引入读写分离，优化初见成效 这类问题引起了我的兴趣和好奇心，经过和业务方沟通了解，这个业务是记录回执数据的，简单来说就好比你发送了一条微博，想看看有多少人已读，有多少人留言等。所以这类场景不存在事务，会有数据的密集型写入，会有明确的统计需求。

[转]如何使用消息队列解决分布式事物 0

Distributed Transaction Solution

[转]如何使用消息队列解决分布式事物

1. 引言 这篇说说分布式事务的问题。企业现在的架构都由传统的架构转向了微服务架构，如下图所示: 那么，都不可避免的会遇到跨数据库调用的，分布式事务问题！ 目前，业内解决分布式事务问题，都基本不用JTA这种强一致性的解决方案，基本是采用如下两套方案 基于TCC的事务框架 消息队列

[转]消息中间件–5消息中间件集群崩溃，如何保证数据不丢失？ 0

RabbitMQ

[转]消息中间件–5消息中间件集群崩溃，如何保证数据不丢失？

“上一篇讲消息中间件的文章《扎心！线上服务宕机时，如何保证数据100%不丢失？》，初步给大家介绍了一个在生产环境中可能遇到的问题，就是你的消费者服务可能会宕机，一旦宕机，你就需要考虑是否会导致没处理完的消息丢失。 这篇文章，再给不太熟悉MQ技术的同学，介绍另外一个生产环境中可能会遇到的问题。

[转]10倍请求压力来袭，你的系统会被击垮吗？ 0

MQ in distributed Architecture

[转]10倍请求压力来袭，你的系统会被击垮吗？

1. 一、背景介绍 背景情况是这样：线上一个系统，在某次高峰期间MQ中间件故障的情况下，触发了降级机制，结果降级机制触发之后运行了一小会儿，突然系统就完全卡死，无法响应任何请求。 给大家简单介绍一下这个系统的整体架构，这个系统简单来说就是有一个非常核心的行为，就是往MQ里写入数据，但是这个往MQ里写入的数据是非常核心及关键的，绝对不容许有丢失。

[转]蚂蚁金服亿级并发下的移动端到端网络接入架构解析 0

Build High Performance System

[转]蚂蚁金服亿级并发下的移动端到端网络接入架构解析

1. 前言 支付宝移动端架构已完成了工具型 App、平台型 App，以及超级 App 三个阶段的迭代与逐步完善。 本次分享将聚焦支付宝在移动网络接入架构的具体演进，以及应对新春红包等项目在亿级并发场景下的具体应对之道。此外，我们将延展探讨蚂蚁金服移动网络技术如何对外商业化应用和输出。