Mobabel

Just One Pure ITer

Category: Distributed Middleware

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

MySQL Master/Slave, R/W Seperation

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

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

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

RabbitMQ

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

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

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

MQ in distributed Architecture

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

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

[转]Twitter的Kafka迁移历程有哪些经验可以借鉴 0

Kafka Practice

[转]Twitter的Kafka迁移历程有哪些经验可以借鉴

Twitter 的实时性特点为 Twitter 的工程团队带来了独特而具有挑战性的问题。我们需要快速发布突发新闻，向用户提供相关广告，并解决很多其他实时性问题。Twitter 的 Pub/Sub 系统为 Twitter 团队提供了处理这些工作负载的基础设施。Twitter 的 Messaging 团队过去几年一直在运行一个内部 Pub/Sub 系统，叫作 EventBus（建立在 Apache DistributedLog 之上），但我们最近决定转向 Apache Kafka，不仅针对已有的用例，还包括新增的用例。在这篇文章中，我们将介绍为什么我们选择采用 Kafka 作为 Twitter 的 Pub/Sub 系统，以及我们在迁移过程中遇到的各种挑战。

[转]消息中间件–4如何保证数据100%不丢失？ 0

MQ in distributed Architecture / RabbitMQ

[转]消息中间件–4如何保证数据100%不丢失？

1. 一、写在前面 上篇文章《同学，消息中间件在你们生产项目里如何落地使用的？》，我们用一个简单易懂的电商场景给大家引入说明了一个消息中间件的使用场景。 同时，我们还基于RabbitMQ的HelloWorld级别的代码，给出了订单服务和仓储服务如何基于MQ中间件收发消息的示例。

[转]百亿大表任意维度查询，如何做到毫秒级返回 0

MySQL Theory & Solution

[转]百亿大表任意维度查询，如何做到毫秒级返回

随着闲鱼业务的发展，用户规模达到数亿级，用户维度的数据指标，达到上百个之多。 如何从亿级别的数据中，快速筛选出符合期望的用户人群，进行精细化人群运营，是技术需要解决的问题。业界的很多方案常常需要分钟级甚至小时级才能生成查询结果。本文提供了一种解决大数据场景下的高效数据筛选、统计和分析方法，从亿级别数据中，任意组合查询条件，筛选需要的数据，做到毫秒级返回。

[转]Redis持久化实战 0

Redis Aof&Rdb Persistence Theory

[转]Redis持久化实战

它支持的数据类型很丰富，如字符串、链表、集合、以及散列等，并且还支持多种排序功能。 1. 什么叫持久化？ 用一句话可以将持久化概括为：将数据（如内存中的对象）保存到可永久保存的存储设备中。 持久化的主要应用是将内存中的对象存储在数据库中，或者存储在磁盘文件中、 XML 数据文件中等等。

0

Redis Theory & Solutions

[总结]Redis热点Key发现及常见解决方案

1. 一、热点Key问题产生的原因 1、用户消费的数据远大于生产的数据（热卖商品、热点新闻、热点评论、明星直播）。 在日常工作生活中一些突发的的事件，例如：双十一期间某些热门商品的降价促销，当这其中的某一件商品被数万次点击浏览或者购买时，会形成一个较大的需求量，这种情况下就会造成热点问题。 同理，被大量刊发、浏览的热点新闻、热点评论、明星直播等，这些典型的读多写少的场景也会产生热点问题。 2、请求分片集中，超过单 Server 的性能极限。 在服务端读数据进行访问时，往往会对数据进行分片切分，此过程中会在某一主机 Server 上对相应的 Key 进行访问，当访问超过 Server 极限时，就会导致热点 Key 问题的产生。 2. 二、热点Key问题的危害 1、流量集中，达到物理网卡上限。 2、请求过多，缓存分片服务被打垮。 3、DB 击穿，引起业务雪崩。 如前文讲到的，当某一热点 Key 的请求在某一主机上超过该主机网卡上限时，由于流量的过度集中，会导致服务器中其它服务无法进行。 如果热点过于集中，热点 Key 的缓存过多，超过目前的缓存容量时，就会导致缓存分片服务被打垮现象的产生。 当缓存服务崩溃后，此时再有请求产生，会缓存到后台 DB 上，由于DB 本身性能较弱，在面临大请求时很容易发生请求穿透现象，会进一步导致雪崩现象，严重影响设备的性能。 3....