There is a plan

2019-10-08

国庆长假过完猛然发现假期效率远比周末泡图书馆低,大概是图书馆旅客太多了吧(疯狂找借口乱甩锅)。

未来的几个月非常关键,于是需要确定个Schedule,各个阶段的不同目标要明确清楚,才容易针对性的突破瓶颈。

Dealing with cache system

缓存系统的设计和应用一直是2C项目缓解压力的利器。和以往使用简单的应用层缓存不同,需要开始对分布式系统和应用层之前的缓存进行学习。

Redis

Redis在经典的3.0版本(也是目前使用特别广泛的版本)后新增了很多新的特性。以往的学习大多是基于旧版本的,缺乏对新的数据结构,新的功能的了解,因此花1周时间,重点关注Redis的新型数据结构,包括Bitmap、HyperLogLog、BloomFilter、Geo以及一些扩展如实现限流用的Redis-Cell。要求完成1篇以上博客形式的学习笔记。

在大流量的系统中依靠单点的缓存系统很难支撑请求,对于Redis集群的实现之前已经有所了解,第二周的目标是搭建一套Redis集群系统,并且尝试Redis分布式锁RedLock的使用,如轮流抢锁进行Print和Sleep。

HTTP & Nginx

HTTP层面的缓存在项目中使用默认配置(目测是没有用上的hhhh),在接下来的一周里面需要丰富HTTP缓存机制的理解,目标是能够手写多种HTTP缓存控制的协商方案流程。

Nginx层面也有一些和HTTP缓存相关的设置,同样在周内了解各个设置的内容,目标是配置Nginx的时候能够不参考文档完成对项目特定内容的缓存控制配置。

Dealing with databases

随着业务的增长,基础数据的数量急剧提升,原有的设计已经有很多地方跟不上新的业务需求。处理大量的数据,需要有对应新的存储方案的设计。

聚焦MySQL的痛点

什么样的数据让数据库撑不住增长压力?由于业务变化,很多业务从之前的周期型统计&展示分析结果逐渐演变成了更有说服力的展示原始的监测数据&分析数据。原始的监控数据,即爬虫抓取的内容,增长量一般会在每日十万、百万,每月数千万,半年内突破亿级。这部分数据既有展示的需要,又要找地方存放,因此需要支持快速取数并且考虑存储成本。

目前,数据一般使用MySQL存放,对于日志型数据,单独开机器存放MySQL的成本较为高,并且也有遇到过磁盘空间不足需要扩容的情况。因此目前需要了解的包括:

  • 日志型数据的存储,如果是非关系型DB的话了解一下使用方法
  • 数据库扩容方案,分批淘汰方案

总体来说,在这一块应该关注的点:

  • MySQL对大数据量,并发要求不高的情况下的方案
  • 非关系型数据库存放日志型数据的方案

在现在的情况下,实际上应该有比MySQL更优秀的成熟的体系去处理这些问题,因为不可能说各种业务数据都用这样的DB来存。希望这个阶段能够接触一些其他的相关知识和新型的存储,深挖MySQL的同时横向扩展知识面,解决数据量持续增长的问题。

本小节目标比较抽象,具体内容和方向还需要调研,因此:

  • MySQL处理方案
    • 周期:1周
    • 目标:学习MySQL扩容、分区等可行方案,思考冷热数据如何分批淘汰,完成1篇学习笔记。
  • 新型DB处理方案
    • 周期:1周
    • 目标:了解是否可以用其他DB解决日志型数据的存储,例如ClickHouse、TiDB(未确认,不了解)等。了解他们的基本原理,为什么比MySQL合适,如何实现,完成1篇学习笔记。

Conclusion

Schedule

  • Redis新型数据类型学习
  • Redis集群学习和实践
  • HTTP&Nginx等非应用层缓存学习
  • MySQL对日志型数据的优化方案
  • 非关系型DB对日志型数据的引用

一共5点,每个内容时限为1周,10月8日起步,DDL为11月5日。评论栏每日打卡,启动!

以上。

嘎。