您现在的位置：首页 --> 查看专题： 分布式
近年来，互联网上安全事件频发，企业信息安全越来越受到重视，而IDC服务器安全又是纵深防御体系中的重要一环。保障IDC安全，常用的是基于主机型入侵检测系统Host-based Intrusion Detection System，即HIDS。在HIDS面对几十万台甚至上百万台规模的IDC环境时，系统架构该如何设计呢？复杂的服务器环境，网络环境，巨大的数据量给我们带来了哪些技术挑战呢？
总有一些看不见的手在控制着软件的世界，就像CAP定理，第一次听到这个词竟然是在面试场合，真的是汗颜，回来之后数次尝试去理解这个定理。英文原文理解不透，中文介绍更是百花齐放百家争鸣，总是感觉一知半解。痛定思痛，决定好好研究一番，并用更加通俗的言语进行解释。
虽然系统越来越复杂，以及新分布式架构设计的思想普及，越来越多的系统采用了分布式的架构，特别是HTTP为交互方式的接口调用，移动端和PC端的并行对分布式架构带来了很大的推动。各式各样的服务接口，在处理业务流程之外有一些共性的问题，正视设计和解决这些问题，会大大提高程序的可用性，扩展性和可维护性。
其实，分布式系统说白了，就是很多机器组成的集群，靠彼此之间的网络通信，担当的角色可能不同，共同完成同一个事情的系统。
在实际生产开发中，遇到一些多节点共存，需要选主，并且要实现HA自动容错的场景，思考了写方法拿出来和大家分享一下。
Seaweedfs 是一个非常优秀的由 golang 开发的分布式存储开源项目，
虽然在我刚开始关注的时候它在 github.com 上面只有 star 50+，
但是我觉得这个项目是一个几千 star 量级的优秀开源项目。
Seaweedfs 的设计原理是基于 Facebook 的一篇图片存储系统的论文 Facebook-Haystack，
论文很长，但是其实原理就几句话，可以看看 Facebook图片存储系统Haystack ，
我觉得Seaweedfs是青出于蓝而胜于蓝。
可能通过「高可用架构」听说过在微博的系统中，单张 MySQL 在线业务表 60 亿条数据的场景。很多关注互联网架构的工程师也非常关注如何如何设计类似系统。下面是一道微博新兵训练营的分布式存储课堂练习，要设计合格才能上岗。
Paxos是一个分布式选举协议，被广泛用在很多分布式系统中，比如Google的Chubby，MegaStore，Linux的Ceph。它的目的是为了让一群机器通过选举的方式达成一个一致性的决议。比如现在有5台MySQL服务器，它们要选举一个Master出来(无人工干预)，所有的数据修改请求都发给这个Master，其它的做为Slave，以备在Master死掉后自动顶上去。
Kubernetes是Google开源的容器集群管理系统。前几天写的 分布式服务框架的4项特性 中提到一个良好的分布式服务框架需要实现 服务的配置管理。包括服务发现、负载均衡及服务依赖管理。 服务之间的调度及生命周期管理。
Swift 最初是由 Rackspace 公司开发的高可用分布式对象存储服务，并于 2010 年贡献给 OpenStack 开源社区作为其最初的核心子项目之一，为其 Nova 子项目提供虚机镜像存储服务。Swift 构筑在比较便宜的标准硬件存储基础设施之上，无需采用 RAID（磁盘冗余阵列），通过在软件层面引入一致性散列技术和数据冗余性，牺牲一定程度的数据一致性来达到高可用性和可伸缩性，支持多租户模式、容器和对象读写操作，适合解决互联网的应用场景下非结构化数据存储问题。
Sheepdog是一个分布式对象存储系统，专为虚拟机提供块存储，号称无单点、零配置、可线性扩展（省略更多优点介绍）。本文主要关注其性能究竟如何，测试版本为目前的最新稳定版0.7.4。
SolrCloud是Solr4.0版本开发出的具有开创意义的基于Solr和Zookeeper的分布式搜索方案，或者可以说，SolrCloud是Solr的一种部署方式。Solr可以以多种方式部署，例如单机方式，多机Master-Slaver方式，这些方式部署的Solr不具有SolrCloud的特色功能。
当我们在生产线上用一台服务器来提供数据服务的时候，我会遇到如下的两个问题：
1）一台服务器的性能不足以提供足够的能力服务于所有的网络请求。
2）我们总是害怕我们的这台服务器停机，造成服务不可用或是数据丢失。
于是我们不得不对我们的服务器进行扩展，加入更多的机器来分担性能上的问题，以及来解决单点故障问题。
Spark是UC Berkeley AMP lab所开源的类Hadoop MapReduce的通用的并行计算框架，Spark基于map reduce算法实现的分布式计算，拥有Hadoop MapReduce所具有的优点；但不同于MapReduce的是Job中间输出和结果可以保存在内存中，从而不再需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的map reduce的算法。
Google Spanner简介 Spanner 是Google的全球级的分布式数据库 (Globally-Distributed Database) 。Spanner的扩展性达到了令人咋舌的全球级，可以扩展到数百万的机器，数已百计的数据中心，上万亿的行。更给力的是，除了夸张的扩展性之外，他还能同时通过同步复制和多版本来满足外部一致性，可用性也是很好的。冲破CAP的枷锁，在三者之间完美平衡。
分布式理论 CAP(Eric Brewer) Web服务无法同时满足以下3个属性 Consistency(一致性)，数据一致更新，所有数据变动都是同步的 Availability(可用性)，每个操作都必须以可预期的响应结束 Partition tolerance(分区容错性)，即使出现单个组件无法可用,操作依然可以完成 在任何数据库设计中,一个Web应用至多只能同时支持上面的两个属性，不可能三者兼顾。对于分布式系统来说，分区容错是基本要求，所以必然要放弃一致性。对于大型网站来说， 分区容错和可用性的要求更高，所以一般都会选择适当放弃一致性。对应CAP理论，NoSQL追求的是AP，而传统数据库追求的是CA，这也可以解释为什么 传统数据库的扩展能力有限的原因。
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。
近3天十大热文
-
[54] IOS安全–浅谈关于IOS加固的几种方法 -
[53] Oracle MTS模式下 进程地址与会话信
-
[52] 如何拿下简短的域名
-
[51] android 开发入门
-
[50] 图书馆的世界纪录
-
[49] 【社会化设计】自我（self）部分――欢迎区
-
[46] Go Reflect 性能
-
[45] 读书笔记-壹百度:百度十年千倍的29条法则
-
[42] 视觉调整－设计师 vs. 逻辑
-
[39] 界面设计速成
赞助商广告
