Mobabel

Just One Pure ITer

Category: Distributed Middleware

[转]消息中间件–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....

[转]消息中间件–2缺点 0

MQ in distributed Architecture

[转]消息中间件–2缺点

这篇文章给大家讲讲，如果你在系统架构里引入了消息中间件之后，会有哪些缺点？ 1. 1 系统可用性降低 首先是你的系统整体可用性绝对会降低，给你举个例子，我们就拿之前的一幅图来说明。

[转]去哪儿网开源消息队列QMQ 0

MQ in distributed Architecture

[转]去哪儿网开源消息队列QMQ

GitHub 开源项目地址传送门： https://github.com/qunarcorp/qmq 1. 背   景 2012 年，随着公司业务的快速增长，公司当时的单体应用架构很难满足业务快速增长的要求，和其他很多公司一样，去哪儿网也开始了服务化改造，按照业务等要素将原来庞大的单体应用拆分成不同的服务。那么在进行服务化改造之前首先就是面临是服务化基础设施的技术选型，其中最重要的就是服务之间的通信中间件。一般来讲服务之间的通信可以分为同步方式和异步方式。同步的方式的代表就是 RPC，我们选择了当时还在活跃开发的 Alibaba Dubbo（在之后 Dubbo 官方停止了开发，但是最近 Dubbo 项目又重新启动了）。 异步方式的代表就是消息队列 (Message Queue)，MQ 在当时也有很多开源的选择：RabbitMQ, ActiveMQ, Kafka, MetaQ(RocketMQ 的前身)。首先因为技术栈我们排除了 erlang 开发的 RabbitMQ，而 Kafka 以及 Java 版 Kafka 的 MetaQ 在当时还并不成熟和稳定。而...

[转]比拼Kafka，大数据分析新秀Pulsar到底好在哪 0

MQ in distributed Architecture

[转]比拼Kafka，大数据分析新秀Pulsar到底好在哪

AI 前线导读： 一年一度由世界知名科技媒体 InfoWorld 评选的 Bossie Awards 于 9 月 26 日公布，本次 Bossie Awards 评选出了最佳数据库与数据分析平台奖、最佳软件开发工具奖、最佳机器学习项目奖等多个奖项。在 最佳开源数据库与数据分析平台奖 中，之前曾连续两年入选的 Kafka 意外滑铁卢落选，取而代之的是新兴项目 Pulsar。 Bossie Awards 中对 Pulsar 点评如下：“Pulsar 旨在取代 Apache Kafka 多年的主宰地位。Pulsar 在很多情况下提供了比 Kafka 更快的吞吐量和更低的延迟，并为开发人员提供了一组兼容的 API，让他们可以很轻松地从 Kafka 切换到 Pulsar。Pulsar 的最大优点在于它提供了比 Apache Kafka...

[转]Kafka如何做到1秒处理1500万条消息？ 0

Kafka Zookeeper Cluster

[转]Kafka如何做到1秒处理1500万条消息？

一位软件工程师将通过本文向您呈现 Apache Kafka 在大型应用中的 20 项最佳实践。 Apache Kafka 是一款流行的分布式数据流平台，它已经广泛地被诸如 New Relic（数据智能平台）、Uber、Square（移动支付公司）等大型公司用来构建可扩展的、高吞吐量的、且高可靠的实时数据流系统。 例如，在 New Relic 的生产环境中，Kafka 群集每秒能够处理超过 1500 万条消息，而且其数据聚合率接近 1Tbps。 可见，Kafka 大幅简化了对于数据流的处理，因此它也获得了众多应用开发人员和数据管理专家的青睐。