• Email:
  • Feeds

  • 基于分发机制的公众订阅平台设计


    如下图所示,一个基于分发机制的公众订阅平台,是指一个移动信息发布系统,可提供订阅功能的系统企业帐号可以给所有的订阅用户按照一定的条件(如地域或用户特征)群发消息,系统的主要关注点包括

    • 分发的throughput。由于群发的放大效应,如何让拥有大量订阅用户的企业帐号能及时投递消息。以及到客户端的移动push通道也存在throughput的问题。
    • 存储的性能,根据客户端的访问型态,如果考虑数据保存在云端,大多需要更新最近联系人、用户与企业订阅帐号之间的会话索引,以及每个会话的未读提醒数。由于客户端本地也可以保存部分数据,因此不同的实现型态可能云端存储及更新的数据有一定差异。
    • 分发及存储模型。分发指数据投递推拉方式的选取,由于筛选条件及通过移动网络主动push的可能性,推送方式可以更好满足业务型态。存储模型指如何选择合适的模型让上万订阅用户的推送能更及时快捷。

    (图中紫色为可能的瓶颈点)

    从图来看,实现并不复杂,但是当系统规模增大之后,如要达到投递即时性需要考验一些工程能力。
    紫色的三个框都可以用key/list来表达,redis的性能和功能可以匹配这样一个场景,这也是为什么近几年redis会如此流行,但离完美匹配类似场景还有一定距离。

    单元化与分布式架构的切分问题

    单元化是将一个系统的架构按某种数据特征维度进行垂直的划分,比如网站有100万用户,如按照用户维度进行划分,则可以分成10个单元,每个单元存储10万用户资料。单元化的一些收益如下

    • 由于每个单元数据规模可控,相关维度内的所有资料可放在一个数据库中(如上例中的用户资料),不需要复杂的sharding分库分表逻辑,存储及缓存访问得到极大的简化。同时开发也变得简单,工程师不需要有丰富的“大规模大并发系统”开发经验。
    • 同时由于计算离存储更近,也可以让数据离用户更近,比如用户数据存储在地理上靠近用户的位置,数据有了更好的局部性(locality),因此也会获得更好的访问性能。部署上相关单元的前端、缓存、数据库、数据挖掘等节点可在同一个机柜,架构上让大数据的访问变得低廉,也在部分程度上让大数据更为快速及敏捷。
    • 可以自然支持不同用户分片支持不同的功能特性,天然的A/B testing试验场。

    分布式是将一个系统的数据分布到多个单元,以便使系统能够scale out,具有更好的可扩展性。当今大型网站基本上是分布式设计的。分布式系统除了机房内的,考虑到系统扩展性、用户访问的便捷性、机房规模的物理限制、异地容灾(比如2013年4月及8月的微信机房故障)等需要,大型系统也会考虑地理分布在多个机房。

    但是在社交网络中,由于数据的网状访问,单元化会碰到较难选择合适的单元化切分维度的问题,比如按用户或按内容进行单元化不能很好的适应数据访问局部性的问题,同时地理分布式也面临相似问题,由于社交网络中用户的页面需要访问的,所有地理分布的机房都同步需要全量数据,导致部署和维护成本较高。

    假定系统中存在一个跨单元的数据访问总线,并且总线的访问满足

    1. 局部性,单元内的访问,大部分的数据可以在单元内命中。
    2. 封装性,单元内的应用程序使用统一的方法访问数据,不需要关注数据的具体位置。

    那么这个数据总线应该如何设计?放在哪个层级比较合适?比如service layer, cache or storage(e.g. Google Spanner)?

    技术晋升的误区


    每到年底,业内不少工程师又需面对晋升答辩的流程,如何让自己在最短的时间完成职级提升是大家关注的话题。在一个规范运作的公司里,基础的晋升通常由部门的经理或者技术负责人定夺,更高级别的评估通常由一个跨部门或公司范围的技术专业委员会(Technical Committee简称TC)来负责。本人有幸参与了几年TC的工作,很高兴看到不少人员的快速成长,但同时看到的一些成长认识误区如下。大家可以通过这些误区的了解,来合理的规划自己的职业生涯,获得更好的职业成长。

    • 罗列工作、项目或者KPI。技术委员会评估一个人的能力时,通常希望寻找论据来支持候选人符合更高级别的Level。但是支持点并不是凭工作量或者项目数的多少来决定。项目按时完成情况是一个辅助因素,但不是全部。因此在所罗列的项目中,寻找那些项目包含了能支撑你胜任高Level去介绍。
    • 没有重点及个人贡献。有些候选人介绍了几个形态各异的项目,但需要评委去仔细挖掘到底体现了候选人哪方面能力;另外一方面有些员工虽然参与了重点及有挑战的项目,但如果其中的个人贡献不好辨别则很难加分。评委可能想“嫦娥三号项目很伟大,可是这个家伙究竟是参与开发了玉兔号月球车,还是仅仅坐在监控大厅看显示器……”。仅强调项目成果评委无法判断候选人的能力,突出重点项目及个人的独特贡献,是材料展示的关键。
    • 承担过的项目与申请的Level不匹配。有些候选人参与过不少项目,对公司也有贡献。但是TC对不同的Level期望候选人展示的能力及规划能力是不同的,越是高阶Level申请,越是看在领域内的规划能力、影响力与愿景,如果目标仅停留在项目完成与否上,不管在哪个级别都会有所欠缺。
    • 可度量及可比性不强。技术行业中,分工越来越细,因此候选人从事一个大家不了解也没参与过的领域的情况越来越多。因此如何将这块的工作的好坏达到一个行业内的可比性也是很重要,帮助TC来理解你的工作。
    • 大篇幅罗列非专业领域的能力,比如项目管理、团队管理、跨团队协调成绩、培养新人成果、项目交付状况、创新成绩等。并不是说这些材料不好或不能讲,但是如果60%以上篇幅都是讲这些,TC无法判断你在专业上是否达到了申请的Level。通常TC对专业角度的考察会占到60%以上的权重。直接说出你打了哪几次胜仗,每场由于环境的变化你灵活使用了哪些兵法来克服困难,在某些特别的条件下,你灵活使用了一些没用过的兵法取得了良好效果。如果你发现过去缺少独立打仗的机会,请看下一条。
    • 岗位成长性差。这一点无关答辩技巧,更多是路线规划与上级主管的培养问题。由于注重结果导向,大部分主管更多精力会放在项目的交付及进度,对下属的安排主要是工作的分配及是否按时完成的监督,而对员工的技术成长、路线规划等则会偏少。碰到这种情况,更多的跟上级在专业发展方面进行交流。确定你的技术成长路线并寻求上级的资源支持,大部分上级也会很乐意提供资源的配合。

    (PS:曾打算写一篇晋升攻略,但考虑到每个人的目标及成长路线的多元化,很难给出公式化的建议,因此仅罗列一些误区供读者思考。)

    Page 1 of 3812345102030...Last »