Mobabel

Just One Pure ITer

Category: Distributed Architecture

0

Theory & Solutions

[转]详解分布式协调服务 ZooKeeper

在 2006 年，Google 发表了一篇名为 The Chubby lock service for loosely-coupled distributed systems 的论文，其中描述了一个分布式锁服务 Chubby 的设计理念和实现原理；作为 Google 内部的一个基础服务，虽然 Chubby 与 GFS、Bigtable 和 MapReduce 相比并没有那么大的名气，不过它在 Google 内部也是非常重要的基础设施。 相比于名不见经传的 Chubby，作者相信 Zookeeper 更被广大开发者所熟知，作为非常出名的分布式协调服务，Zookeeper 有非常多的应用，包括发布订阅、命名服务、分数是协调和分布式锁，这篇文章主要会介绍 Zookeeper 的实现原理以及常见的应用，但是在具体介绍 Zookeeper 的功能和原理之前，我们会简单介绍一下分布式锁服务...

0

Build High Performance System

[转]以“前浪微博”场景为例，谈谈架构设计流程四步曲

让我们结合复杂度来源和架构设计原则，通过一个模拟的设计场景“前浪微博”，和你一起看看在实践中究竟如何进行架构设计。 我们假想一个创业公司，名称叫作“前浪微博”。前浪微博的业务发展很快，系统也越来越多，系统间协作的效率很低，例如： 用户发一条微博后，微博子系统需要通知审核子系统进行审核，然后通知统计子系统进行统计，再通知广告子系统进行广告预测，接着通知消息子系统进行消息推送……一条微博有十几个通知，目前都是系统间通过接口调用的。每通知一个新系统，微博子系统就要设计接口、进行测试，效率很低，问题定位很麻烦，经常和其他子系统的技术人员产生分岐，微博子系统的开发人员不胜其烦。 用户等级达到 VIP 后，等级子系统要通知福利子系统进行奖品发放，要通知客服子系统安排专属服务人员，要通知商品子系统进行商品打折处理……等级子系统的开发人员也是不胜其烦。

0

Nginx

[转]Nginx宣布正式支持gRPC，附示例代码

  NGINX 官方博客正式宣布 NGINX 支持原生的 gPRC，现在就可以从代码仓库拉取快照版本。该特性将会被包含在 NGINX OSS 1.13.10、NGINX Plus R15 以及 NGINX 1.13.9 当中。 NGINX 已经能够代理 gRPC TCP 连接，用户可以用它： 发布 gRPC 服务，并应用 NGINX 提供的 HTTP/2 TLS 加密机制、速率限定、基于 IP 的访问控制以及日志等功能。 在单个端点上发布多个 gRPC 服务，使用 NGINX...

Ähnliches Foto 0

Database Partitioning&Scaling

[总结]分表分库时机选择及策略

1. 一. 分表 1-1. 应用场景： 对于大型的互联网应用来说，数据库单表的记录行数可能达到千万级甚至是亿级，并且数据库面临着极高的并发访问。采用Master-Slave复制模式的MySQL架构，只能够对数据库的读进行扩展，而对数据库的写入操作还是集中在Master上，并且单个Master挂载的Slave也不可能无限制多，Slave的数量受到Master能力和负载的限制。 因此，需要对数据库的吞吐能力进行进一步的扩展，以满足高并发访问与海量数据存储的需要！

Bildergebnis für 火车 0

MQ in distributed Architecture

[转]分布式系统之消息队列

1. 2. 一、MQ简介 消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题，实现高性能，高可用，可伸缩和最终一致性架构。 使用较多的消息队列有ActiveMQ，RabbitMQ，ZeroMQ，Kafka，MetaMQ，RocketMQ 3. 二、消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景。异步处理，应用解耦，流量削锋和消息通讯四个场景。

0

Redis High Avaliable Scale Architect

[转]一个包含10节点的Redis集群实践案例

Redis 通常不会被用作主要的数据存储，但它在存储和访问可容忍丢失的临时数据（如度量指标、会话状态、缓存）方面却独有长处，并且速度非常快，不仅提供了最佳性能，还内置了一组非常有用的数据结构。它是现代技术栈中最常见的主要部件之一。 Stripe（一家做支付的硅谷创业公司）的速率限定器就是基于 Redis 构建的，这些限速器运行在一个 Redis 实例上。Redis 主服务器有一些用于失效备援的追随者，不过在任何时候，都只有一个节点在处理读写操作。 各种消息来源声称，一个 Redis 节点每秒可以处理百万次操作。尽管我们的操作没有那么多，但也不会很少。每个速率限定器都需要运行多个 Redis 命令，而每个 API 请求都要通过很多个速率限定器。所以，每个节点每秒钟需要处理数万次到数十万次的操作。 如果节点出现饱和，就会不断出现故障。我们的服务可以容忍 Redis 的不可用，因此大多数情况下是没有问题的，但在某些情况下，问题的严重程度会升级。我们最后通过迁移到包含 10 节点的 Redis 集群来解决这个问题。对性能的影响可以忽略不计，重要的是现在我们可以实现水平可伸缩。