最新 | 最热门 | 最高评价

+0  2PC之踵?是时候升级二阶段提交协议了

Tag: 分布式
Tim 发于 2019年01月28日 10:32 | 点击: 298 | 展开摘要
感谢读者,能看到这篇文章,也许是通过 RSS 订阅或者是博客首页来的。博客过去很长时间没有更新,大部分随想都发表在微博,由于发的内容大多是碎碎念,建议大家也不用专门去拜访。在 2010 年时候,曾写过一篇多IDC的数据分布设计的文章提到过 2PC 等协议,最近在 Hackernews 上又有很多有关优化 2PC 讨论,讨论的源头主要由下面这篇文章引起的,因此作了翻译,供大家参阅。

两阶段提交协议(2PC)已经在企业软件系统中使用了三十多年。它是一种非常有影响力的协议,用于确

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

+0  分布式系统中唯一ID的生成

Tag: Distributed System | ID | Service | 分布式
四火 发于 2017年06月30日 23:59 | 点击: 1353 | 展开摘要
其实老早就像写一点这个话题。几乎我见过的所有大型系统中,都需要一个唯一ID的生成逻辑。别看小小的ID,需求和场景还挺多:

这个ID多数为数字,但有时候是数字字母的组合;

可能随机,也可能要求随时间严格递增;

有时ID的长度和组成并不重要,有时候却要求它严格遵循规则,或者考虑可读性而要求长度越短越好;

某些系统要求ID可以预期,某些系统却要求ID随机性强,无法猜测(例如避免爬虫等等原因)。

独立的生成服务

比如数据库。最常见的一种,也是应用最多的一种,就是利用数据库

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

+0  从Gitlab误删除数据库想到的

Tag: 技术新闻 | 程序设计 | 系统架构 | Design | Gitlab | High Availability | Programmer | 分布式 | 程序员
陈皓 发于 2017年02月02日 16:11 | 点击: 1407 | 展开摘要
昨天,Gitlab.com发生了一个大事,某同学误删了数据库,这个事看似是个低级错误,不过,因为Gitlab把整个过程的细节都全部暴露出来了,所以,可以看到很多东西,而对于类似这样的事情,我自己以前也干过,而在最近的两公司中我也见过(Amazon中见过一次,阿里中见过至少四次),正好通过这个事来说说一下自己的一些感想和观点吧。我先放个观点:你觉得有备份系统就不会丢数据了吗?

事件回顾

整个事件的回顾Gitlab.com在第一时间就放到了Google Doc上,事后,又发了

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

+0  关于高可用的系统

Tag: 技术管理 | 程序设计 | 系统架构 | Design | High Availability | Paxos | Programmer | 分布式 | 程序员
陈皓 发于 2016年08月21日 12:34 | 点击: 1273 | 展开摘要
在《这多年来我一直在钻研的技术》这篇文章中,我讲述了一下,我这么多年来一直在关注的技术领域,其中我多次提到了工业级的软件,我还以为有很多人会问我怎么定义工业级?以及一个高可用性的软件系统应该要怎么干出来?这样我也可以顺理成章的写下这篇文章,但是没有人问,那么,我只好厚颜无耻的自己写下这篇文章了。哈哈。

另外,我在一些讨论高可用系统的地方看到大家只讨论各个公司的技术方案,其实,高可用的系统并不简单的是技术方案,一个高可用的系统其实还包括很多别的东西,所以,我觉得大家对高可用的

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

+0  持续可用与分布式协议

Tag: 未分类 | 持续可用,Paxos,分布式协议
chuanhui 发于 2015年04月12日 16:53 | 点击: 1590 | 展开摘要

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

Tag: 分布式
Hao Luo 发于 2015年03月19日 21:10 | 点击: 3606 | 展开摘要
【编者的话】本文作者通过ZooKeeper与Eureka作为Service发现服务(注:WebServices体系中的UDDI就是个发现服务)的优劣对比,分享了Knewton在云计算平台部署服务的经验。本文虽然略显偏激,但是看得出Knewton在云平台方面是非常有经验的,这篇文章从实践角度出发分别从云平台特点、CAP原理以及运维三个方面对比了ZooKeeper与Eureka两个系统作为发布服务的优劣,并提出了在云平台构建发现服务的方法论。

背景

很多公司选择使用ZooKe

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

+0  从未降级的搜索技术-实时之刃

Tag: 其他 | 分布式技术 | 搜索引擎 | 实时流量调控 | 实时计算 | 搜索架构
桂南 发于 2014年12月09日 17:00 | 点击: 1486 | 展开摘要
流量是互联网变现的基石,而流量的资源是有限的,如何实现资源的最大化利用(买家-商品的最高效的匹配)是此次双11搜索技术深度切入的使命,也是第一次在双11通过实时把握资源流动的脉搏来控制资源的收和放。

一.  问题发现

天猫的业务团队同学,通过针对去年双11细致认真的数据分析,发现了去年双11暴露的一些问题。 预热期

小部分商品预热过度,预热期吸引的加购量远超出商品库存能支撑的量,大部分用户虽然加了购物车但当天也抢不到,购物车转化率低;而大部分商品预热不足,没有充分曝光;

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

+0  从未降级的搜索技术-Hippo在线服务调度系统

Tag: 分布式技术 | 自动化运维 | 调度系统
路仁 发于 2014年11月29日 18:10 | 点击: 2337 | 展开摘要
          很久很久以前,有一个PE叫川小生,有一个开发叫子小嘉。双11前,他们按照业务的要求给天猫准备了14倍余量,给主 搜准备了1倍余量。结果11号上午流量涨势喜人啊,嗖嗖往上涨。川小生和子小嘉说不对啊,怎么主搜涨这么厉害天猫只涨4倍呢,川小生掐指一 算,干,到 晚上主搜就挂了啊。俩人怂了,把天猫机器迁一点给主搜吧。于是改clustermap下机器,发binary,发依赖数据,发全量,追增量,起进程,改 clustermap加机器,一通折腾一个半小时过去,总算有惊

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

+0  从未降级的搜索技术 – HBase集群升级与优化

Tag: 分布式技术 | 性能优化 | Hadoop | hbase
雨田 发于 2014年11月26日 18:22 | 点击: 1501 | 展开摘要
战争从来都是拼后勤拼平台支撑的,天猫双十一这一天对于我们搜索事业部来说,就是一场高强度的数字化战争。为了这一天,各兄弟业务线的战友们已经摩拳擦掌,纷纷亮出各种新式武器,而我们原有的离线系统平台却渐渐显出疲态,慢慢被来自各业务线的不断提升的压力需求搞得捉襟见肘了。个性化搜索实时数据处理平台(Pora)在双十一将正式亮相,当时我们预计会有数以十亿计的新增HBase读写请求,如果不进行升级优化,原有的离线集群预计将无法承受这一前所未有的压力;天猫业务线的增量在双十一更是重中之重,届

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

+0  分布式服务框架的4项特性

Tag: 分布式
Tim 发于 2014年10月31日 09:34 | 点击: 1291 | 展开摘要
在移动及云时代,尽管大部分可扩展的问题可以通过云平台解决,但是服务本身的扩展性挑战仍然存在。比如一个新的项目,用PHP或JSP实现了基本功能,部署在Apache或Tomcat等容器上,在业界这种部署在一个容器内的功能模块通常可以称为一个service。服务容器很容易通过EC2或者docker等方式来扩展部署更多的实例。但service本身的管理的以下几个方面的问题仍然需要架构师去设计及解决。

1、服务的远程调用(RPC)。

随着系统的用户访问规模增大,以及系统功能的增多,

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

+0  SSDB 分布式的一些想法

Tag: Computer System | SSDB | SSDB分布式
ideawu 发于 2014年10月26日 12:03 | 点击: 7260 | 展开摘要
到目前为止, SSDB 还是一个单机存储方案, 存储容量受到单机硬盘的限制, 虽然 SSDB 可以自动压缩数据, 将存储容量提高 10 倍以上, 但还是在 TB 级别. 不少 SSDB 的用户一直在呼唤 SSDB 分布式, SSDB 集群, 但是千呼万唤不出来. 为什么?

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

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

+0  分布式配置服务etcd VS 分布式协调服务zookeeper

Tag: CoreOS | 分布式
xiaoding 发于 2014年10月20日 17:16 | 点击: 2928 | 展开摘要
背景

coreOS中使用了etcd作为集群配置服务,拥有众多出色的特点,etcd是一个key,value的数据服务器,单实例可达每秒 1000 次写操作,以及方便的REST接口。 zookeeper则是在Hadoop中大放光彩的分布式协调服务,提供了分布式锁,数据同步,等服务。

从功能上看,二者都可以很好的完成集群中分布式中遇到的同步,配置问题,但是不可否认,这2种服务在设计的时候的目的不同,也让这2中服务有着不小的差异。

etcd

目的:一个高可用的 Key/Val

查看全文: http://www.udpwork.com/item/13408.html
|<<<1234567>>>| 一共8页, 90条记录