IT牛人博客聚合

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

longhao 发于 2012年09月15日 16:32 | 点击: 11040 | 展开摘要

1：分布式理论

CAP(Eric Brewer)

Web服务无法同时满足以下3个属性

Consistency(一致性)，数据一致更新，所有数据变动都是同步的

Availability(可用性)，每个操作都必须以可预期的响应结束

Partition tolerance(分区容错性)，即使出现单个组件无法可用,操作依然可以完成

在任何数据库设计中,一个Web应用至多只能同时支持上面的两个属性，不可能三者兼顾。

查看全文: http://www.udpwork.com/item/8117.html

+5 玩转Protocol Buffers

桂南发于 2012年09月18日 10:09 | 点击: 9789 | 展开摘要

1. 人人都爱Protocol Buffers

1.1 Protocol Buffers（PB）是什么?

Protocol buffers are Google’s language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define ho

查看全文: http://www.udpwork.com/item/8132.html

---

+0 Paxos小议

Tag: 分布式基础 | paxos | 分布式 | 选举算法

editor 发于 2011年11月23日 15:08 | 点击: 9388 | 展开摘要

问题

最近我们在做一个项目的时候有这样一个需求：我们有多台服务器资源，希望彼此协作完成一项工作。这项工作可以被划分为N个小的模块，但由于这项工作会依赖于持续不断的输入(在线业务)，因此我们无法使用人工指定的方式将此工作分发到不同服务器进行。目前我们想到一个方法，将这项工作划分出的小模块放到一个稳定可靠的地方，例如mola存储系统，然后每台服务器去存储系统上取得一定数量的模块进行工作，完成后再将处理的结果输出到前述的存储系统上。这些小的模块虽然可以被不同的服务器运行，然后重复

查看全文: http://www.udpwork.com/item/6367.html

---

+0 分布式基础通信协议:paxos,totem和gossip

Tag: 分布式

xiaoding 发于 2014年05月13日 05:55 | 点击: 8275 | 展开摘要

背景

在分布式中，最难解决的一个问题就是多个节点间数据同步问题。为了解决这样的问题，涌现出了各种奇思妙想。只有在解决了如何进行信息同步的基础之上才衍生出形形色色的应用。这里开始介绍几种分布式通信协议。

简单即有效——totem协议:

totem协议也许你还比较陌生，但是corosync就是totem协议的一个开源实现。比较火的HA软件pacemaker就是基于corosync来提供各种服务的。说起totem协议，最简单的形象就是，他将多个节点组成一个令牌环。多个节点手拉

查看全文: http://www.udpwork.com/item/12562.html

^..^

+0 SSDB 分布式的一些想法

Tag: Computer System | SSDB | SSDB分布式

ideawu 发于 2014年10月26日 12:03 | 点击: 8060 | 展开摘要

到目前为止, SSDB 还是一个单机存储方案, 存储容量受到单机硬盘的限制, 虽然 SSDB 可以自动压缩数据, 将存储容量提高 10 倍以上, 但还是在 TB 级别. 不少 SSDB 的用户一直在呼唤 SSDB 分布式, SSDB 集群, 但是千呼万唤不出来. 为什么?

分布式数据存储是一个真正的技术难道, 不说各种理论, 最简单的是数据怎么迁移. 想想, 原来你只有一个存储节点, 但数据多了之后, 硬盘存不下, 这时怎么把一部分数据迁移到另一个新的存储节点? 这就是数据

查看全文: http://www.udpwork.com/item/13434.html

+1 Facebook Haystack图片存储架构

Tag: 分布式架构 | Facebook Haystack，图片存储，淘宝TFS

chuanhui 发于 2010年12月05日 22:43 | 点击: 7830 | 展开摘要

OSDI 10中有一篇Facebook图片存储系统Haystack的论文，名称为”Finding a needle in Haystack: Facebook’s photo storage”。从这篇论文可以看出，数据量大的应用有时也并不复杂。

我们先给Facebook图片存储系统算一笔账。Facebook目前存储了260 billion图片，总大小为20PB，通过计算可以得出每张图片的平均大小为20PB / 260GB，约为800KB。

查看全文: http://www.udpwork.com/item/4068.html

---

+0 Microsoft Azure存储架构设计

Tag: 分布式架构 | Azure Architecture | Azure Internal | Distributed Architecture | SQL Azure Design

chuanhui 发于 2010年11月13日 21:08 | 点击: 7430 | 展开摘要

SQL Azure简介

SQL Azure是Azure存储平台的逻辑数据库，物理数据库仍然是SQL Server。一个物理的SQL Server被分成多个逻辑分片(partition)，每一个分片成为一个SQL Azure实例，在分布式系统中也经常被称作子表(tablet)。和大多数分布式存储系统一样，SQL Azure的数据存储三个副本，同一个时刻一个副本为Primary，提供读写服务，其它副本为Secondary，可以提供最终一致性的读服务。每一个SQL Azure实例

查看全文: http://www.udpwork.com/item/4071.html

---

+0 Amazon Dynamo – 纠结的设计

Tag: 分布式架构 | Amazon Dynamo，纠结的设计

chuanhui 发于 2011年03月22日 22:43 | 点击: 6897 | 展开摘要

从09年第一次阅读Dynamo论文，到最近阅读Amazon S3的一篇专利，一路过来对论文的理解可以简单归结为两个字 – 纠结。第一次看到Amazon Dynamo论文，有一种眼前一亮的感觉，Dynamo通过巧妙地组合一些P2P技术在Amazon构建了一个工程上可行的系统，CAP，NWR, Vector Clock一时成为流行词，更为神奇的是，Dynamo号称能够让用户设置不同的NWR策略从而在CAP三者之间获得一个很好的权衡，鱼和熊掌亦可兼得。而Amazon S

查看全文: http://www.udpwork.com/item/4571.html

^..^

+0 Cassandra存储机制

NinGoo 发于 2010年02月25日 17:17 | 点击: 6533 | 展开摘要

Author:NinGoo posted on NinGoo.net
在2009年兴起的NoSQL运动中，Cassandra是其中重要的一个分布式key-value数据库产品，由Facebook在2008年开源，目前是Apache的顶级项目。最近twitter的一篇声明，表示将从MySQL迁移到Cassandra，更让其声名大振。Cassandra是结合了Google Bigtable的数据模型和Amazon Dynamo高可用框架的一个产品。其数据模型可以参考张瑞的blo

查看全文: http://www.udpwork.com/item/1688.html

---

+0 分布式系统的事务处理

陈皓发于 2014年01月20日 11:08 | 点击: 4794 | 展开摘要

当我们在生产线上用一台服务器来提供数据服务的时候，我会遇到如下的两个问题：

1）一台服务器的性能不足以提供足够的能力服务于所有的网络请求。

2）我们总是害怕我们的这台服务器停机，造成服务不可用或是数据丢失。

于是我们不得不对我们的服务器进行扩展，加入更多的机器来分担性能上的问题，以及来解决单点故障问题。通常，我们会通过两种手段来扩展我们的数据服务：

1）数据分区：就是把数据分块放在不同的服务器上（如：uid % 16，一致性哈希等）。

2）数据镜像：让所有的服务器

查看全文: http://www.udpwork.com/item/11599.html

^..^

+0 Beanstalkd 一个高性能分布式内存队列系统

Tag: Beanstalkd | beanstalk | beanstalkd | 内存队列 | 分布式

千石发于 2011年09月13日 20:29 | 点击: 4399 | 展开摘要

之前在微博上调查过大家正在使用的分布式内存队列系统，反馈有Memcacheq, Fqueue, RabbitMQ , Beanstalkd以及linkedin的kafka。RabbitMQ使用比较广泛，Beanstalkd是后起之秀。Beanstalkd之于RabbitMQ，就好比Nginx之于Apache，Varnish之于Squid。后面在项目中使用Beanstalkd的过程中，更发现其简单、轻量级、高性能、易使用等特点，以及优先级、多队列、持久化、分布式容错、超时控制等

查看全文: http://www.udpwork.com/item/5887.html

---

+0 [转] 为什么不应该使用ZooKeeper做服务发现

Tag: 分布式

Hao Luo 发于 2015年03月19日 21:10 | 点击: 4233 | 展开摘要

【编者的话】本文作者通过ZooKeeper与Eureka作为Service发现服务(注：WebServices体系中的UDDI就是个发现服务)的优劣对比，分享了Knewton在云计算平台部署服务的经验。本文虽然略显偏激，但是看得出Knewton在云平台方面是非常有经验的，这篇文章从实践角度出发分别从云平台特点、CAP原理以及运维三个方面对比了ZooKeeper与Eureka两个系统作为发布服务的优劣，并提出了在云平台构建发现服务的方法论。

背景

很多公司选择使用ZooKe

查看全文: http://www.udpwork.com/item/14005.html

|<<<12 3 4 5 6 7 >>>| 一共12页, 133条记录

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

+5 玩转Protocol Buffers

+0 Paxos小议

+0 分布式基础通信协议:paxos,totem和gossip

+0 SSDB 分布式的一些想法

+1 Facebook Haystack图片存储架构

+0 Microsoft Azure存储架构设计

+0 Amazon Dynamo – 纠结的设计

+0 Cassandra存储机制

+0 分布式系统的事务处理

+0 Beanstalkd 一个高性能分布式内存队列系统

+0 [转] 为什么不应该使用ZooKeeper做服务发现

JS 在线图表制作

RSS 订阅

微信订阅

Tags

Random Sites

Hot Items

Site Reviews

Item Reviews