无限容量数据库架构设计
花了不少时间，把自己曾经做过的系统，曾经遇到到的问题，曾经实践过的架构方案，梳理总结和沉淀，尽量“系统的”记录成文字，和大家一起讨论。
本文是不同业务场景下，体系化的介绍“数据库水平切分”技术，和大家分享。
一、总起
文章：《每每谈到数据库架构，我们在讨论什么》
内容：
- 单库体系架构
- 数据库分组架构
- 数据库分片架构
- 数据库垂直切分
简单介绍 10 个常见的软件架构
有没有想过如何设计大型企业及系统？在开发之前，我们必须要选择一个合适的架构，以保证我们软件的功能和质量。今天就简单介绍一下常用的 10 个架构。
什么是架构？
一直以来，在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。甚至于很多架构师一说架构，就开始谈论什么应用架构、硬件架构、数据架构等等。我曾经也到处寻找过架构的定义，请教过很多人，结果发现，没有大家都认可的定义。套用一句关于 big data 流行的笑话，放在架构上也适用：
Architecture is like teenage sex，everybody talks about it，nobody really knows what is it。
事实上，架构在软件发明时的 N 多年以前，就已经存在了，这个词最早是跟随着建筑出现的。在软件工程中，架构以理解为：
- 根据要解决的问题，对目标系统的边界进行界定。
- 并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。
- 并对这些切分出来的部分，设立沟通机制。
- 根据 3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。
理解RESTful架构
越来越多的人开始意识到，网站即软件，而且是一种新型的软件。
这种"互联网软件"采用客户端/服务器模式，建立在分布式体系上，通过互联网通信，具有高延时（high latency）、高并发等特点。…
软件架构入门
软件架构（software architecture）就是软件的基本结构。
合适的架构是软件成功的最重要因素之一。大型软件公司通常有专门的架构师职位（architect），只有资深程序员才可以担任。
O'Reilly 出版过一本免费的小册子《Software Architecture Patterns》（PDF）， 介绍了五种最常见的软件架构，是非常好的入门读物。我读后受益匪浅，下面就是我的笔记。…
TCP接入层的负载均衡、高可用、扩展性架构
一、web-server的负载均衡
互联网架构中，web-server接入一般使用nginx来做反向代理，实施负载均衡。整个架构分三层：
整个访问过程为：
- browser向daojia.com发起请求
- DNS服务器将daojia.com解析为外网IP(1.2.3.4)
- browser通过外网IP(1.2.3.4)访问nginx
- nginx实施负载均衡策略，常见策略有轮询，随机，IP-hash等
- nginx将请求转发给内网IP(192.168.0.1)的web-server
由于http短连接，以及web应用无状态的特性，理论上任何一个http请求落在任意一台web-server都应该得到正常处理（如果必须落在一台，说明架构不合理，不能水平扩展）。
问题来了，tcp是有状态的连接，客户端和服务端一旦建立连接，一个client发起的请求必须落在同一台tcp-server上，此时如何做负载均衡，如何保证水平扩展呢？
二、单机法tcp-server
单个tcp-server显然是可以保证请求一致性：
- client向tcp.daojia.com发起tcp请求
- DNS服务器将tcp.daojia.com解析为外网IP(1.2.3.4)
- client通过外网IP(1.2.3.4)向tcp-server发起请求
方案的缺点？
无法保证高可用。
三、集群法tcp-server
通过搭建tcp-server集群来保证高可用，客户端来实现负载均衡：
- client内配置有tcp1/tcp2/tcp3.daojia.com三个tcp-server的外网IP
关于实时推送系统的那点事
大家好，我是于小波，2011年加入魅族，现在在魅族移动互联网部门，主要负责服务端后台架构设计和开发工作。…
实时系统架构与实践
实时系统架构与实践
概要
分享基于 MQTT 协议的、面向移动互联网的 实时消息、实时统计、实时在线系统的架构设计；团队在云主机、部署自动化、监控自动化实践；团队在高性能分布式 Key/Value 存储的实践。 听众受益： 了解 MQTT 协议在移动互联网、智能设备上使用的优势， 了解大型实时系统的基本架构设计原理， 小团队如何利用云端资源快速实现、运营产品， 自动化 部署、监控 系统及实践方法， 高性能 Key/Value 系统的新设计理念
http://www.infoq.com/cn/presentations/framework-and-implementation-of-real-time-system…
到底什么时候该使用MQ？
一、缘起
一切脱离业务的架构设计与新技术引入都是耍流氓。
引入一个技术之前，首先应该解答的问题是，这个技术解决什么问题。
就像微服务分层架构之前，应该首先回答，为什么要引入微服务，微服务究竟解决什么问题（详见《互联网架构为什么要做微服务？》）。…
消息总线真的能保证幂等？
一、缘起
如《消息总线消息必达》所述，MQ消息必达，架构上有两个核心设计点：
（1）消息落地
（2）消息超时、重传、确认
再次回顾消息总线核心架构，它由发送端、服务端、固化存储、接收端四大部分组成。
为保证消息的可达性，超时、重传、确认机制可能导致消息总线、或者业务方收到重复的消息，从而对业务产生影响。
举个栗子：
购买会员卡，上游支付系统负责给用户扣款，下游系统负责给用户发卡，通过MQ异步通知。不管是上半场的ACK丢失，导致MQ收到重复的消息，还是下半场ACK丢失，导致购卡系统收到重复的购卡通知，都可能出现，上游扣了一次钱，下游发了多张卡。
消息总线的幂等性设计至关重要，是本文将要讨论的重点。
二、上半场的幂等性设计
MQ消息发送上半场，即上图中的1-3
1，发送端MQ-client将消息发给服务端MQ-server
2，服务端MQ-server将消息落地
3，服务端MQ-server回ACK给发送端MQ-client
如果3丢失，发送端MQ-client超时后会重发消息，可能导致服务端MQ-server收到重复消息。
此时重发是MQ-client发起的，消息的处理是MQ-server，为了避免步骤2落地重复的消息，对每条消息，MQ系统内部必须生成一个inner-msg-id，作为去重和幂等的依据，这个内部消息ID的特性是：
（1）全局唯一
（2）MQ生成，具备业务无关性，对消息发送方和消息接收方屏蔽
有了这个inner-msg-id，就能保证上半场重发，也只有1条消息落到MQ-server的DB中，实现上半场幂等。
三、下半场的幂等性设计
MQ消息发送下半场，即上图中的4-6
4，服务端MQ-server将消息发给接收端MQ-client
5，接收端MQ-client回ACK给服务端
6，服务端MQ-server将落地消息删除
需要强调的是，接收端MQ-client回ACK给服务端MQ-server，是消息消费业务方的主动调用行为，不能由MQ-client自动发起，因为MQ系统不知道消费方什么时候真正消费成功。
如果5丢失，服务端MQ-server超时后会重发消息，可能导致MQ-client收到重复的消息。
此时重发是MQ-server发起的，消息的处理是消息消费业务方，消息重发势必导致业务方重复消费（上例中的一次付款，重复发卡），为了保证业务幂等性，业务消息体中，必须有一个biz-id，作为去重和幂等的依据，这个业务ID的特性是：
（1）对于同一个业务场景，全局唯一
（2）由业务消息发送方生成，业务相关，对MQ透明
原六种网络应用架构模式
六种网络应用架构模式
六种网络应用架构模式，以socket编程为例讲解。
一、串行化
处理请求的串行化模型。
在串行化架构中，所有的客户端连接是依次进行处理的，因为不涉及并发，多个客户端不会同时接受服务。
串行化架构最大的优势在于它的简单性。没有锁，没有共享状态，处理完一个连接之后才能处理另一个。在资源使用方面亦是如此：一个实例处理一个连接，一个萝卜一个坑，绝不多消耗资源。
串行化架构明显的劣势是不能并发操作。即便是当前连接处于空闲，也不能处理等待的连接。…
近期评论