Mobabel

Just One Pure ITer

Category: Distributed Middleware

[转]删库了，除了跑路还能怎么办？ 0

MySQL Theory & Solution

[转]删库了，除了跑路还能怎么办？

1. 写在前面 虽然我们之前遇到的大多数的数据被删，都是运维同学或者 DBA 背锅的。但实际上，只要有数据操作权限的同学，都有可能踩到误删数据这条线。 今天我们就来聊聊误删数据前后，我们可以做些什么，减少误删数据的风险，和由误删数据带来的损失。

0

Kafka Practice

[总结]Kafka性能调优和参数调优

Kafka的配置详尽、复杂，想要进行全面的性能调优需要掌握大量信息，这里只记录一下我在日常工作使用中走过的坑和经验来对kafka集群进行优化常用的几点。

[转]新浪日访问量百亿级的应用如何做缓存架构设计 0

Cache in distributed Architecture / Redis High Avaliable Scale Architect

[转]新浪日访问量百亿级的应用如何做缓存架构设计

微博日活跃用户1.6亿+，每日访问量达百亿级，面对庞大用户群的海量访问，良好架构且不断改进的缓存体系具有非常重要的支撑作用。刷微博吗？跟我们一起听听那些庞大的数据是如何呈现的吧！ 陈波：大家好，今天的分享主要有以下内容，首先是微博在运行过程中的数据挑战，然后是Feed系统架构，接下来会着重分析Cache架构及演进，最后是总结、展望。

[转]同程RocketMQ如何应对每天1500亿条的数据处理？ 0

RocketMQ

[转]同程RocketMQ如何应对每天1500亿条的数据处理？

同程艺龙的机票、火车票、汽车票、酒店相关业务已经接入了 RocketMQ，用于流量高峰时候的削峰，以减少后端的压力。 同时，对常规的系统进行解耦，将一些同步处理改成异步处理，每天处理的数据达 1500 亿条。 在近期的 Apache RocketMQ Meetup 上，同程艺龙机票事业部架构师查江，分享了同程艺龙的消息系统如何应对每天 1500 亿条的数据处理。 通过此文，您将了解到： 同程艺龙消息系统的使用情况 同程艺龙消息系统的应用场景 技术上踩过的坑 基于 RocketMQ 的改进

[转]携程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...

[转]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...