专题：分布式 -- IT技术博客大学习 -- 共学习共进步！

近年来，互联网上安全事件频发，企业信息安全越来越受到重视，而IDC服务器安全又是纵深防御体系中的重要一环。保障IDC安全，常用的是基于主机型入侵检测系统Host-based Intrusion Detection System，即HIDS。在HIDS面对几十万台甚至上百万台规模的IDC环境时，系统架构该如何设计呢？复杂的服务器环境，网络环境，巨大的数据量给我们带来了哪些技术挑战呢？

一文读懂分布式系统CAP定理

总有一些看不见的手在控制着软件的世界，就像CAP定理，第一次听到这个词竟然是在面试场合，真的是汗颜，回来之后数次尝试去理解这个定理。英文原文理解不透，中文介绍更是百花齐放百家争鸣，总是感觉一知半解。痛定思痛，决定好好研究一番，并用更加通俗的言语进行解释。

分布式程序设计早知道-关于分布式程序设计常见问题分析

虽然系统越来越复杂，以及新分布式架构设计的思想普及，越来越多的系统采用了分布式的架构，特别是HTTP为交互方式的接口调用，移动端和PC端的并行对分布式架构带来了很大的推动。各式各样的服务接口，在处理业务流程之外有一些共性的问题，正视设计和解决这些问题，会大大提高程序的可用性，扩展性和可维护性。

分布式系统设计系列 -- 基本原理及高可用策略

其实，分布式系统说白了，就是很多机器组成的集群，靠彼此之间的网络通信，担当的角色可能不同，共同完成同一个事情的系统。

分布式选主 -- 利用Mysql ACID和Lease协议实现选主和高可用

在实际生产开发中，遇到一些多节点共存，需要选主，并且要实现HA自动容错的场景，思考了写方法拿出来和大家分享一下。

分布式存储Seaweedfs源码分析

Seaweedfs 是一个非常优秀的由 golang 开发的分布式存储开源项目，虽然在我刚开始关注的时候它在 github.com 上面只有 star 50+，但是我觉得这个项目是一个几千 star 量级的优秀开源项目。 Seaweedfs 的设计原理是基于 Facebook 的一篇图片存储系统的论文 Facebook-Haystack，论文很长，但是其实原理就几句话，可以看看 Facebook图片存储系统Haystack ，我觉得Seaweedfs是青出于蓝而胜于蓝。

微博分布式存储作业实现方法

可能通过「高可用架构」听说过在微博的系统中，单张 MySQL 在线业务表 60 亿条数据的场景。很多关注互联网架构的工程师也非常关注如何如何设计类似系统。下面是一道微博新兵训练营的分布式存储课堂练习，要设计合格才能上岗。

使用逻辑时钟重述paxos协议

Paxos是一个分布式选举协议，被广泛用在很多分布式系统中，比如Google的Chubby，MegaStore，Linux的Ceph。它的目的是为了让一群机器通过选举的方式达成一个一致性的决议。比如现在有5台MySQL服务器，它们要选举一个Master出来(无人工干预)，所有的数据修改请求都发给这个Master，其它的做为Slave，以备在Master死掉后自动顶上去。

Kubernetes – Google分布式容器技术初体验

Kubernetes是Google开源的容器集群管理系统。前几天写的分布式服务框架的4项特性中提到一个良好的分布式服务框架需要实现服务的配置管理。包括服务发现、负载均衡及服务依赖管理。服务之间的调度及生命周期管理。

Openstack Swift简介

Swift 最初是由 Rackspace 公司开发的高可用分布式对象存储服务，并于 2010 年贡献给 OpenStack 开源社区作为其最初的核心子项目之一，为其 Nova 子项目提供虚机镜像存储服务。Swift 构筑在比较便宜的标准硬件存储基础设施之上，无需采用 RAID（磁盘冗余阵列），通过在软件层面引入一致性散列技术和数据冗余性，牺牲一定程度的数据一致性来达到高可用性和可伸缩性，支持多租户模式、容器和对象读写操作，适合解决互联网的应用场景下非结构化数据存储问题。

分布式对象存储系统Sheepdog性能测试

Sheepdog是一个分布式对象存储系统，专为虚拟机提供块存储，号称无单点、零配置、可线性扩展（省略更多优点介绍）。本文主要关注其性能究竟如何，测试版本为目前的最新稳定版0.7.4。

分布式全文检索系统SolrCloud简介

SolrCloud是Solr4.0版本开发出的具有开创意义的基于Solr和Zookeeper的分布式搜索方案，或者可以说，SolrCloud是Solr的一种部署方式。Solr可以以多种方式部署，例如单机方式，多机Master-Slaver方式，这些方式部署的Solr不具有SolrCloud的特色功能。

分布式系统的事务处理

当我们在生产线上用一台服务器来提供数据服务的时候，我会遇到如下的两个问题： 1）一台服务器的性能不足以提供足够的能力服务于所有的网络请求。 2）我们总是害怕我们的这台服务器停机，造成服务不可用或是数据丢失。于是我们不得不对我们的服务器进行扩展，加入更多的机器来分担性能上的问题，以及来解决单点故障问题。

分布式缓存的一起问题

主要出于可用性及高性能的考虑。传统的架构使用基于一致性哈希的分布式缓存，数据只存在一份副本，在出现cache节点单点故障时，虽然可以由一致性哈希算法将请求均匀落到其他节点，但由于穿透的请求较多，仍然给数据库带来较大的访问压力。为了避免对数据穿透带来的冲击，数据使用两份副本可以避免穿透的问题。同时在数据访问较大时候，也可以更好的分担流量，避免峰值单份数据跑满对系统带来的冲击。

分布式消息系统尝试(rabbitmq, celery, redis)

最近在调整游戏的后台架构，之前因为需要快速出产品，所以整个代码都揉成一团，也基本没有做任何分层处理。现在服务器端的开发也开始逐渐招进来，所以打算打算换一套统一的架构，以后做新游戏只要做其中的业务逻辑即可。

Spark：一个高效的分布式计算系统

Spark是UC Berkeley AMP lab所开源的类Hadoop MapReduce的通用的并行计算框架，Spark基于map reduce算法实现的分布式计算，拥有Hadoop MapReduce所具有的优点；但不同于MapReduce的是Job中间输出和结果可以保存在内存中，从而不再需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的map reduce的算法。

Ceph的现状

Ceph是统一分布式存储系统，具有优异的性能、可靠性、可扩展性。Ceph的底层是RADOS(可靠、自动、分布式对象存储)，可以通过LIBRADOS直接访问到RADOS的对象存储系统。RBD(块设备接口)、RADOS Gateway(对象存储接口)、Ceph File System(POSIX接口)都是基于RADOS的。

全球级的分布式数据库 Google Spanner原理

Google Spanner简介 Spanner 是Google的全球级的分布式数据库 (Globally-Distributed Database) 。Spanner的扩展性达到了令人咋舌的全球级，可以扩展到数百万的机器，数已百计的数据中心，上万亿的行。更给力的是，除了夸张的扩展性之外，他还能同时通过同步复制和多版本来满足外部一致性，可用性也是很好的。冲破CAP的枷锁，在三者之间完美平衡。

分布式知识的总结(V1.0)

分布式理论 CAP(Eric Brewer) Web服务无法同时满足以下3个属性 Consistency(一致性)，数据一致更新，所有数据变动都是同步的 Availability(可用性)，每个操作都必须以可预期的响应结束 Partition tolerance(分区容错性)，即使出现单个组件无法可用,操作依然可以完成在任何数据库设计中,一个Web应用至多只能同时支持上面的两个属性，不可能三者兼顾。对于分布式系统来说，分区容错是基本要求，所以必然要放弃一致性。对于大型网站来说，分区容错和可用性的要求更高，所以一般都会选择适当放弃一致性。对应CAP理论，NoSQL追求的是AP，而传统数据库追求的是CA，这也可以解释为什么传统数据库的扩展能力有限的原因。

多IDC环境下的分布式id分配方案

id分配是社区类产品的提交环节中必不可少的一步。任何UGC类内容产生时往往需要分配一个对应的id。 id分配的几种方式方式一：单点自增分配。全局由一个模块来负责生成id，可保证id从0开始连续递增，数据一般放在本地文件。简洁，但致命的问题是单点故障会导致服务整体不可用。方式一改进：为该模块提供主从复制的能力，或者干脆将数据放在mysql里，利用mysql的主从复制，都一定程度上增强了可用性，减轻了单点故障的影响。方式二：随机/散列分配。通过一些hash算法，比如以时间+随机串为key的md5生成一个唯一的id，关键点在于算法和key的选择要避免冲突。最典型的就是UUID，UUID的标准型式包含32个16进位数字，以连字号分为五段，形式为8-4-4-4-12的32个字符，如550e8400-e29b-41d4-a716-446655440000。