最新 | 最热门 | 最高评价

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

Tag: 分布式
Hao Luo 发于 2015年03月19日 21:10 | 点击: 4298 | 展开摘要
【编者的话】本文作者通过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 | 点击: 2645 | 展开摘要
流量是互联网变现的基石,而流量的资源是有限的,如何实现资源的最大化利用(买家-商品的最高效的匹配)是此次双11搜索技术深度切入的使命,也是第一次在双11通过实时把握资源流动的脉搏来控制资源的收和放。

一.  问题发现

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

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

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

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

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

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

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

Tag: 分布式
Tim 发于 2014年10月31日 09:34 | 点击: 1913 | 展开摘要
在移动及云时代,尽管大部分可扩展的问题可以通过云平台解决,但是服务本身的扩展性挑战仍然存在。比如一个新的项目,用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 | 点击: 8141 | 展开摘要
到目前为止, 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 | 点击: 3573 | 展开摘要
背景

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

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

etcd

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

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

+0  面向分布式系统工程师的分布式系统理论

Tag: 分布式系统 | 翻译
youngsterxyf 发于 2014年08月10日 00:00 | 点击: 4248 | 展开摘要
原文:Distributed systems theory for the distributed systems engineer

译者:youngsterxyf

Gwen Shapira,大腕级的解决方案架构师(SA),如今Cloudera的全职工程师,在Twitter上提的一个问题引起了我的思考。

如果是以前,我可能会回答“嗯,这里有篇FLP论文,这里有篇Paxos论文,这里还有篇拜占庭将军问题的论文...”,我会罗列一箩筐重要的材料,如果你一头扎进去,至少花费6

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

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

Tag: 分布式
xiaoding 发于 2014年05月13日 05:55 | 点击: 8345 | 展开摘要
背景

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

简单即有效——totem协议:

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

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

+0  HQueue:基于HBase的消息队列

Tag: 其他 | 分布式技术 | hbase | HQueue | HQueue Toolkit | HQueue订阅
凌柏 发于 2014年04月24日 14:35 | 点击: 1963 | 展开摘要
​1. HQueue简介

HQueue是一淘搜索网页抓取离线系统团队基于HBase开发的一套分布式、持久化消息队列。它利用HTable存储消息数据,借助HBase Coprocessor将原始的KeyValue数据封装成消息数据格式进行存储,并基于HBase Client API封装了HQueue Client API用于消息存取。

HQueue可以有效使用在需要存储时间序列数据、作为MapReduce Job和iStream等输入、输出供上下游共享数据等场合。

​2.

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

+0  使用HBase EndPoint(coprocessor)进行计算

Tag: 分布式技术 | coprocessor | endpoint | hbase
震河 发于 2014年03月31日 10:54 | 点击: 2868 | 展开摘要
如果要统对hbase中的数据,进行某种统计,比如统计某个字段最大值,统计满足某种条件的记录数,统计各种记录特点,并按照记录特点分类(类似于sql的group by)~

常规的做法就是把hbase中整个表的数据scan出来,或者稍微环保一点,加一个filter,进行一些初步的过滤(对于rowcounter来说,就加了FirstKeyOnlyFilter),但是这么做来说还是会有很大的副作用,比如占用大量的网络带宽(当标级别到达千万级别,亿级别之后)尤为明显,RPC的量也是不容

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

+0  hbase failover状态下启动慢原因排查

Tag: 分布式技术
tianzhao 发于 2014年03月21日 17:50 | 点击: 1705 | 展开摘要
某天我们升级hbase,从hbase-0.94.5升到hbase-0.94.10,当然这些版本里面有自己加入的部分patch。

启动后,看master页面,发现很多region还没有online,在慢慢的open中。是什么原因呢?jstack发现master在执行processDeadServersAndRecoverLostRegions过程,在一个region一个region的处理,而集群总共有3w多个region,300百台机器,3w个region一个个处理,写zk,

查看全文: http://www.udpwork.com/item/11990.html
|<<<2345678>>>| 一共12页, 133条记录