• Feeds

  • 工程师如何规划新的一年计划

    最近碰到了一个创业失败的朋友,由于资金紧张,暂时没有合适的事情可做,只好靠开滴滴度日。问了他下一步的打算,他说有个传统企业的老板想转型互联网+,也很有兴趣跟他合作,未来打算将自己的重点放在这方面。

    “但是他也可能三年都不会有所动作,将自己主要计划放在这方面会不会太被动了一点?” 我提醒他。

    很多时候,我们面临 hard 模式和 easy 模式选择的时候,大部分人会下意识的选择 easy 模式,即使在 easy 模式不自主可控的情况下。人们容易对未来的计划抱有侥幸心理,相信美好的事情必会发生。

    年轻的时候也存在类似的幻想,每当做 new year resolution 时候,把自己那些可能潜在希望发生的事情盘点了一遍,放进了自己新年前三的计划列表之中,但半年过去后,那些抱有很大希望的事情并没有发生。回过头细想,有些是期望机会从天而降;有些可能是合作对象随口一说,在对方眼里,也是极低优先级,这样的话没什么进展就很自然了。

    在职场当中,大家也通常有类似的想法,在新的一年,自我感觉过去表现不错,等待上司给自己更重要的担子;或者自我感觉优秀,等待伯乐给自己做千里马的机会。怀有这样的想法无可厚非,但是如果将自己大部分未来押注在这些期望上面,则成长与未来很难掌控。

    至少要将大部分计划投入在自己可以掌控的方向,尤其是在学习及自我提升方面,这样在最坏的情况下也会有所收获。即使那些成长快的人,也只是极少部分时间碰上好运,大部分时间需要靠主动去规划自己的时间来掌控未来。

    law1

    相关阅读

    王渊命老师讨论此话题时推荐了一本书读《程序员的思维修炼》

    前年看的一本书,今年才有体会,逐渐落到了实处:程序员的思维修炼。
    制定学习计划应该也用 SMART 方法:具体的(Specific),可度量的(Measurable),可实现的(Attainable),相关的(Relevant),时间可控的(Time-bound)。

    未来的学习

    作者注:本文发表于 2015 年 12 月 24 日。

    平安夜在中国是个跟宗教无关的节日,即使不忙的人在这晚也需要假装日程很紧。中关村的基督教堂依旧像往年一样人头涌涌;路边的餐厅很多提前下班了,那些年轻的服务员也需要在这个夜晚去释放他们的青春。而在另外一边,在互联网的虚拟世界里,一大群工程师正在 2015 年平安夜通过网络参与一个 Hadoop 及 HBase 年度回顾的「高可用架构」群直播分享活动。

    在线直播是最近在很多垂直社区流行的一种分享方式,讲师通过社交、通讯或在线教育 app,以语音或者图文的方式向所有在线收听的用户传授知识,而听课的人群可以利用移动 app 的优势,随时随地参与学习及交流。

    在罗辑思维中提到

    在一个信息泛滥的时代,信息本身零价值,信息渠道也不再值钱。传播的枢纽是魅力人格体。

    世界上没有那么多魅力人格体,但每个领域都不缺意见领袖。在 IT 领域尤其是技术领域,知识的升级迭代速度非常快,因此从业群体需要比其他行业更多更快的学习新知识及了解新资讯。因此有大量人群被这些垂直领域的意见领袖聚集在群、自媒体等社交渠道周围。比如上面提到群直播,就是一些活跃在前沿的讲师给大家讲授业界最前沿的热点技术内容,参与人员也会通过群提供的二维码给讲师打赏,在群中通常戏称为“交学费”。

    而在线下,也有另外一些不同的新的玩法。极客邦科技(InfoQ 中国背后的公司)今年成立了一个技术人学习组织 EGO,会员主要以公司技术负责人为主。Tim 由于也是其中的会员之一,因此有机会结识了很多新的会员。这些加入会员也是在自己的职业生涯某些方面存在困惑,公司的工作太忙,网上的信息太庞杂,去校园进修又不太现实,因此其实很缺乏高效的线下学习途径。

    Tim 在与这些会员交流的过程中,发现大部分人在他们相关的领域非常优秀,也慢慢了解他们所属公司最近几年的发展历程,了解他们所在的不同行业的发展情况,也了解到他们在不同领域的奋斗、成长与得失。Tim 也很喜欢这种交流的过程,一方面,与这些行业优秀的技术人一起可以快速学到他们身上的优点及特长,同时也可以通过他们了解到许多以前不了解的领域。

    一次一个会员问了 Tim 一个非常好的问题,“你最近在这个组织得到的最大收获是什么?”

    对于 Tim 而言,如上所述,最大的收获是跟不同会员的深度交流,学习会员做事的方法与理念,了解他们对于行业方向的判断、以及对于技术的态度及选择。

    这也是每个人加入一个学习组织或者线上群体经常思考的问题,为什么要来到这里?你在这里一段时间的收获是什么?

    在论坛中,我们的主要诉求是内容及人的发现,内容方面包括发现有价值、值得收藏的内容,同时通过内容发现背后有思想的人,通过在社区交流观点,用户之间产生互动,从而在贡献内容之余彼此熟悉,形成社区。所以,在一个论坛一年的收获通常是发现了有价值的内容,结识了值得结识的朋友。

    在移动时代,传统的论坛方式慢慢被其他更移动及社交化的方式代替,用户更多时间停留在社交及通讯的 app 中。Tim 今年也创建了一系列「高可用架构」群,主要关注互联网架构领域的内容传播,虽然不如传统的论坛那么正式及严谨,但慢慢也聚集了一大批各个公司的技术群体,一起讨论各种技术及非技术的话题。

    群直播分享相对与传统的技术会议及技术媒体,非常不正式,目前也算不上主流的交流或学习方式。一篇采访张泉灵的采访中,提到她眼中新接触的一些新的互联网产品印象。

    傅盛给我看他的一个投资,叫“小余老师说”,做视频的项目,当时在优酷上,很早期一集就有一百多万点击量。傅盛得意地跟我说,你看我投了一个特别有特质的孩子。我是做媒体的,视频看了很多,当时我特别不屑一顾:它的LOGO和背景完全一个颜色,“小余老师说”五个行草不规则叠在同样颜色的花色背景上,节目上的小余老师背后是一个斑马纹的欧式椅子,他人又不高,椅背整个呼在后面。看完我完全疯掉了,说这东西凭什么?

    傅盛跟我说,其实你要理解的事情是现象及规律——一个东西在互联网上,有一百万的点击,而且能持续,就一定不只凭运气。你的重点不是想凭什么是他,而是你要想为什么是他。想明白之后,你还要理解,互联网对某样东西的认可,是带着资本和传播势能的。

    当时我找了团队里的90后,说把B站最火的视频统统给我看一遍。我一边看一边崩溃,一边还要理解:视频有三层弹幕,你根本不知道后面是什么,三层弹幕密密麻麻的,一个字都看不清,还唱那样的歌。但你要慢慢理解这种亚文化的背后是什么,这些用户是谁。

    很多基于社交及通讯软件新的学习方式也是如此,这些方式可能充满了噪音,学习效率也存在问题,手机上浏览及参与也不便,产出也不稳定,质量良莠不齐,但无法逃避的问题是,我们的大部分时间停留在此。在这里,一旦有优质的内容,就会有更快的速度传遍这个圈子的每一个角落。这也是为什么非常多朋友选择这种方式并帮助一起去进化它。

    有人说,一个男人变老的两大标志是不断后退的发际线和不断增长的腰围。

    其实,一个人真正变老的标志是,他觉得人生一眼望得到投,不会再有改变。

    于是放弃了学习,放弃了提升自己。

    「你一年的 8760 小时」

    微博分布式存储作业实现方法

    可能通过「高可用架构」听说过在微博的系统中,单张 MySQL 在线业务表 60 亿条数据的场景。很多关注互联网架构的工程师也非常关注如何如何设计类似系统。下面是一道微博新兵训练营的分布式存储课堂练习,要设计合格才能上岗。

    关注为什么超长列表数据的翻页技术实现复杂的读者请直接参看文末链接。

    feeds2

    考虑到网上有很多架构师也在讨论,补充题目一些说明如下。

    1、访问场景

    由于上面题目的应用场景,用户一般情况下,主要查看用户查看自己收到的最新的微博,以及某个特定用户 profile 的所有微博。

    • 收到的微博,考虑微博以拉为主的模式,则需要访问关注用户最近 n 条最新的微博。
    • 用户 profile,需要访问用户历史上所有发表的微博,而且支持分页查看,可以直接跳转到某一页或者某个时间段,因此需要适当考虑分页的效率(可参考扩展阅读)。

    访问特征

    • 从上面描述以及社交网络的用户访问特点来看,用户大部分情况( > 90% )是访问最近 7 天的数据。

    不需要考虑的点

    • 此题主要是存储层的设计,因此不需要考虑缓存如何设计。
    • 由于微博是异步写入的,在某种程度可以起到错峰作用,所以作业暂时不需要考虑写入的峰值。
    • 不需要考虑 id 如何产生,假定已经有发号服务。
    • 不需要考虑用户收到的微博怎么聚合,那个是更上层服务层的职责。

    2、设计需要考虑的点

    Scale-out 扩展性

    • 将数据拆分到多个独立的单元存储
    • 可以在适当时机进一步拆分,拆分时候需要继续提供在线访问
    • 存储在廉价硬件上,考虑到数据规模比较大,需要适当考虑方案的整体成本,因此不要假定默认全部使用 SSD 存储。

    Cost 成本

    • 不同访问级别的数据存储在不同访问速度(成本)的硬件上。

    High availability 高可用,以及 Reliability 可靠性 – 复制

    在当前场景下,主要通过 MySQL replication 来解决可用性、以及分担读的请求。

    3、Sharding 策略

    Shard 常用策略

    range based:根据用户 uid 来分布,相邻 uid 的数据保存在一起。
    hash based:根据某个 hash 函数,将一个用户 uid 的数据保存在指定的分片。

    Re-Sharding 拆分设计
    当数据持续增长,原先存储的数据(或者访问量)超过当前节点的容量上限,则需要对节点进行进一步拆分。

    feeds3

    如何确定shard数量

    db buffer > hot data

    容量规划

    • 预规划: 容纳未来一段时间的数据
    • 2 的指数倍: shard 数量变更简单

    Tradeoff

    • 分片多:影响 IO 效率;
    • 分片少:扩容频繁、复杂

    4、部分投稿案例

    案例一:使用 user id range 作为分片

    case1

    案例二:使用user id hash作为分片

    case2

     

    方案三 (via 张亮)
    历史数据:
    1. 每半年根据日期分库,如:2015.01-2015.06为一个库。每天增加1亿数据,半年180亿,约为0.72T数据,可以保留在1T的磁盘中。
    2. 根据 uid 取模分库(表),便于查询和分散数据。

    当前 n 日数据:
    1. 暂定n为10,存储10亿数据。
    2. 根据uid + 权重的hash算法分库。权重可以根据每个uid的微博id数量,粉丝数等指标离线计算。

    hash算法需保证:
    1. 同一uid需落在一个库。
    2. 权重接近的用户尽量均匀的落在不同库。
    3. 为了应对突然发生的事件导致访问量激增,需要考虑2级甚至3级分片,而不宜直接做re-sharding导致数据迁移。多级分片可考虑读取一个标记,放在zk中。根据标记确定分片的hash算法加入小时等维度。

    查询索引:
    1. 增加发帖索引字段,记录每个用户的每个帖子的索引。
    2. 增加发帖总数统计表,以用户为维度,每个用户发一次贴则发帖总数++。
    3. 增加二级索引表,记录每个用户,每次分片库的发帖索引。如:uid 1的用户,在2015年第一帖是该用户发帖的总数的第10贴,2015年最后一贴是该用户发帖总数的第50贴。
    4. 分页查询使用二级索引表,先查到该查哪个真实库(可能是多个),再到真实库中获取数据。

    总结:
    1. 通过灵活的运用时间维度分片,免去因uid分片数量不足导致的大规模迁移,使用外部flag灵活的控制分片策略。而且用时间维度分片更易做到冷热分离。
    分片逻辑可以灵活到,zk中记录时间段,某个时间段内,按月分,某个时间段,按年分,之类。
    2. 通过离线计算权重的方式均匀分散数据访问。权重周期性调整,对于调整权重的用户,需要重点考虑当前n日数据的数据迁移方案。但由于调整权重的用户属于少量,所以迁移应该数据变动较小。历史数据不需权重概念,无需数据迁移。
    3. 查询使用二级索引。使用修改btree结构去掉二级索引能有效减少数据量,但实现难度较大,可以在之后的局部优化中实现,对总体数据库结构影响不大。
    4. 将前n日数据和当天数据整合在一起,之前对微博的场景理解不深,以为有首屏显示这样的概念。

     

    5、扩展阅读

    关于分页:
    为什么超长列表数据的翻页技术实现复杂
    为什么超长列表数据的翻页技术实现复杂(二)