inlfuxdb源码分析-文件结构（二）

发表于 2018-08-20

inlfuxdb源码分析-文件结构（二）

存储数据结构

influxdb的存储引擎为改进lsm tree，叫做tsm tree.
关于lsm tree其核心的思想就是：将对数据的修改增量保持在内存中，达到指定的大小限制后将这些修改操作批量写入磁盘。改随机写为顺序写，对写多读少的场景又很强的优化效果

参考:

lsm tree 论文

lsm存储模型

文件结构

tsm文件

一个tsm文件的构成：Header， Blocks， Index，Footer

4bytes Magic number, 1byte Version

MagicNumber uint32 = 0x16D116D1
Version byte = 1

Blocks:

Block 由CRC校验4个字节，已经Data 字节组成。 Data 的数据解压后的格式为 8 字节的时间戳以及紧跟着的 value，value 根据类型的不同，会占用不. 同大小的空间，其中 string 为不定长，会在数据开始处存放长度，这一点和 WAL 文件中的格式相同。

Index

Index 存放的是前面 Blocks 里内容的索引。索引条目的顺序是先按照 key 的字典序排序，再按照 time 排序。InfluxDB 在做查询操作时，可以根据 Index 的信息快速定位到 tsm file 中要查询的 block 的位置

查找时，会根据Key做二分查找，找到key在block中的偏移，取出数据。

inlfuxdb源码分析（一）

发表于 2018-08-14

inlfuxdb源码分析（一）

介绍

不多说了，需要对时序数据有了解参考

官网

源码编译

clone代码

从github上clone代码到本地$GOPATH/influxdata/influxdb

安装依赖

cd $GOPATH/influxdata/influxdb

go get ./...

安装过程中你会发现有问题，我在master分支和1.4，1.5版本始终没有解决，
1.3版本下编译通过。需要根据Godeps文件下的库文件的comment id来切换自己库的相关依赖

编译influxd

cd $GOPATH/influxdata/influxdb/cmd/influxd/

go build

启动可执行文件

./influxd

下节将从influxd这个包开始看代码

如何提高代码质量

发表于 2018-05-26

如何提高代码质量

思路

目标：远景上下达成一致。并非为了增加工作量，为了提高代码质量已经代码水平。
客观：用数据说话，多维度的数据支撑
措施可落地，方式大家都认可
工具化，自动化（review， sonar）

标准

度量代码质量的指标是什么（千行代码严重错误率，千行代码缺陷）
标准如何确定（参考业界标准，公司内其他业务线标准？）

反馈

关键指标趋势（是否有好转）

参考

质量运营在智能支付业务测试中的初步实践

git flow

发表于 2018-05-26

背景

这几年一直在用git，但是一直感觉一直没用好，原因还是多人协助的大型项目比较少。最近在做前后端分离的项目，多人协作，并且接入公司发布系统，这个时候统一的git工作流就显得非常重要了。问题如下

在什么分支进行开发？
用什么分支部署到测试环境？
用什么分支部署到线上环境？
改bug时候怎么处理？
pull request怎么用？

带着这些问题，对使用最广泛的git flow进行了学习，规范大家的工作流。

git flow

分支

master 主分支，永远保证稳定的发布版本，长期存在
develop 开发分支，日常开发的最新代码，会比master分支的内容多，长期存在
feature 功能分支，开发新功能时从develop拉取，开发完成merge回develop, 删除该分支
release 发布分支，在上线条件ok之后，从develop拉出，之后不做任何新功能添加，只修改bug，最后release就要合并回master, 同时合回develop
bugfix，修复分支，从master， develop拉出，修完同样合回去，删除掉

工作流

假设现在有个`git@github.com:test/portal.git`的项目，clone下来，下面开始开发

拉出开发分支
```
git branch develop
git push origin develop
```
现在已经有了master和develop两个长期存在的分支

我要开发新功能了new_job了！
```
git checkout -b feature_new_job develop 
git add
git commit -m "awsome work"
git push
```
从develop创建新的分支，名字叫feature_new_job，然后都在上面提交

新功能new_job已经开发完了！

    git checkout develop.
    git pull
    git merge feature_new_job
    git push
    git branch -d feature_new_job

切到develop分支，获取最新代码，合并feature_new_job分支， 提交代码到develop， 删除feature_new_job分支。

在测试环境测试develop分支

准备发版了
```
git checkout -b release_0.0.1 develop
git push
```
改bug， push。。。改bug， push。

代码没问题了！！！真的要上线了

git checkout master
git merge release_0.0.1
git push

还要合回到develop分支

git checkout develop
git merge release-0.1.0
git push
git branch -d release-0.1.0

对运维的思考

发表于 2018-05-15

对运维的一些思考

随着网站流量越来越大，故障发生的频率也越来越高。怎么能减少故障的时间呢，加快故障处理速度？
当业务发生问题之后，运维能做什么？
运维在平时除了日常的变更工作，还有做什么工作帮助业务发现问题，解决问题？
运维开发团队又能为业务和运维提供哪些服务，解放运维的工作，帮助业务减少问题的出现？

对以上问题，在总结故障之后，得出自己的一些思考

故障前

总结之前的故障，发现更多的情况是业务方并没有按照运维提供的标准做事。
我的理解，运维在日常的变更工作之外，最重要的事情就是制定标准。只有标准化一切，否则自动化运维更是无从谈起
具体的标准有哪些呢？

硬件规格
操作系统
基础配置
中间件版本，使用规范
代码规范
部署路径
日志路径
如何监控，监控哪些指标（非常重要）
….

等等等等，只要能想到可以标准化的事情，全部做到有标准，有规范。对我们的团队来说可能是处在有标准，但是没有和业务共识。所以如何将标准落地，如何拉进运维和业务开发的距离非常重要。个人认为，运维一定要离业务很近，和业务开发穿一条裤子，才能保证所运维业务的稳定，以及更加快速的处理问题。这就像业务开发必须离需求很近，运维开发要离运维很近一个道理

故障前运维还能做什么？比如，故障的预案，有了预案就需要故障的演练，甚至在新业务上线之前，如何评估容量，压力。这些都需要运维从自己的多年经验的角度和开发一起做这些事。

故障中

当故障发生之时，运维又能做什么呢？协助开发排查问题，用自己的经验通过蛛丝马迹快速定位问题。用各种强大的自动化系统如日志，监控，tracing等系统快速解决问题。

不过我认为，除非真的是运维本身的问题，比如网络，服务器磁盘等问题，如果真的是业务开发自己的代码bug，在故障中，查找问题之时，运维还是很难帮助到开发排查问题的。

真正要做到的还是在故障前落实标准

故障后

我觉得不论运维还是开发，对每一次故障都要有刨根问底儿的精神。故障的原因究竟是什么？为什么会发生？如何避免？以后遇到的解决办法是什么？开发和运维要做到一起复盘一遍。不是为了甩锅，是为了让系统更健壮，故障不在发生。

这里我觉得有两个关键点很重要：

用事实说话：分析故障原因不能靠猜，要用事实来说话，当时每个节点的日志是什么？对应故障发生时间有什么变更操作，记录是什么？等等
故障报告很重要：详细的故障报告书写，沉淀成为知识库。对后人，对自己都是有很大的帮助

运维开发能做啥？

运维开发团队做什么事情才能算是真正帮助到运维了，才能算是一个有意义有成就感的团队，我的理解有如下几点

对标准

通过一系列的自动化运维系统，帮助运维落地标准。比如集中的PAAS层约束中间件使用标准，发布系统约束开发代码标准，完备的监控系统（很重要）约束监控规范等等

对运维的日常工作

开发团队的存在就是为了解放运维的生产力，不管哪个系统我自己总结就是需要有流畅的体验，说起来简单，但是要是想让运维，甚至开发们有这种体验，做起来还是有很长的路要走的

对外提供的服务

运维开发团队和运维也会对开发去提供基础的一些服务，比如PAAS层的一些服务，发布等等。运维的系统可能量不会很大但对于这些系统来说以下两点尤为重要

高效问题的提供服务
准确的数据

每个系统做到以上两点以及可以及格了

其他

说了几次监控很重要，因为他是真的很重要，我们把监控叫做运维之眼，运维能不能睡好觉，监控至关重要。这里只想说一点，每个业务最好去定义自己的关键指标，而关键指标必须保证能告警。这个指标可能是url，可能是qps。总之需要运维和业务一起商量确定

React learning

发表于 2016-09-25

事情要从饿了么这个前端库说起。偶然在微博上看到eleme团队开源了这个叫element的前端库，看下源码是基于vue的。顺着评论又看到了阿里的 ant.design, 感觉各种漂亮。如果以后能在自己的项目中统一使用这一套，那逼格杠杠的。而且阿里云之类的中后台貌似都是用的这一套。
看了一下介绍：

1.Designed as Ant Design，提炼和服务企业级中后台产品的交互语言和视觉风格。

2.React Component 基础上精心封装的高质量 UI 组件。

3.基于 npm + webpack + babel 的工作流，支持 ES2015 和 TypeScript。

vue之前看过，而且实际项目中也用到了，只是没有用得到组件这块的内容。React刚出来的时候看了一下，当时感觉比较复杂就放弃看了。没想到现在发展的这么好。要想用起antd这一套，看来要从React入手

###感悟

React两天看下来感觉还可以。但毕竟不是专业前端人员，而且这几年的前端发展感觉太快了，已经打破的我工作之初对html, css, js的理解。现在搞得什么gulp, webpack， scss，less，还有Weex, Redux这些东西，我真的是有些晕菜了。。。

###目标

现在的目标就是把antd搞起来试一下！

open-falcon 技术分享会总结

发表于 2016-04-09

open-falcon 技术分享会总结

滴滴出行

滴滴出行主要介绍了open-falcon v0.1.0的新特性，以及未来open-falcon未来的规划

新特性

graph扩容不再丢失数据
自定义dashboard
自定义汇报时间间隔（放到配置中）
支持openTSDB
适配Grafana-一个全球广泛使用的dashboard
集群监控
nodata监控
文档完善

规划

前端模块合并（dashboard, portal）
权限控制
API重新整理设计
组合策略告警， tag反选（不等于某一条件时报警）

美团 `mt-falcon`

美团机器2w+，监控指标5kw+，open-falcon集群100+台服务器

动态服务树整合：机器上有告警接收人，策略中也有告警接受人，告警时取并集发送
字符串监控（监控日志信息）
Docker监控：最早为宿主机监控
告警合并：第一条告警直接发送，之后的告警通过提取主机组字段合并发送。机器合并，同一metric合并好做。服务依赖直接的告警合并不好处理
UI重构
服务内嵌：把汇报代码直接打入Lib包，不用安装agent
告警屏蔽：可以选择屏蔽主机，策略。最多2周，2周后恢复。

运维、监控的一些思考

一切为了运维友好，解放生产力
open-falcon本身的日志需要更加完善
监控的路线为：基础监控–>聚合监控–>智能监控（定位，自愈）。基础监控尤为重要

Q&A

Q: open-falcon的自监控如何处理？

A: 生产环境下很少需要运维，因为设计上无核心down点。有anti-eye的工具来监控每个模块

Q: 与服务树如何对接？

A: 同步机器列表。open-falcon只做监控，对于资产的对接需要开发完成。具体怎么对接的滴滴和美团都没有太详细说明

Q:open-falcon如何去单点

A:美团多机房部署

Q:graph历史数据的迁移

A：美团SSD，3T硬盘，定期删除数据

Q: zibbix数据如何迁移？

A：数据不迁移。在zabbix和open-falcon共存阶段，数据同时往两个地方写入

Q: 模板的对接问题？

A：模板还是open-falcon的模板，权限自己开发

django class based view 代码分析

发表于 2016-04-09

django class based view 代码分析

url.py入手

class view url配置一般这样写

url(r'^module_detail/(?P<pk>(\d+))/$' ModuleDetailView.as_view(), name='module_detail'),

关键方法是as_view()。

as_view() 源码

as_view()方法实际是个闭包，返回了一个处理函数，把class view 变成了function view，源码如下：


@classonlymethod
def as_view(cls, **initkwargs):
    """
    Main entry point for a request-response process.
    """
    for key in initkwargs:
        if key in cls.http_method_names:
            raise TypeError("You tried to pass in the %s method name as a "
                            "keyword argument to %s(). Don't do that."
                            % (key, cls.__name__))
        if not hasattr(cls, key):
            raise TypeError("%s() received an invalid keyword %r. as_view "
                            "only accepts arguments that are already "
                            "attributes of the class." % (cls.__name__, key))

    def view(request, *args, **kwargs):
        self = cls(**initkwargs)
        if hasattr(self, 'get') and not hasattr(self, 'head'):
            self.head = self.get
        self.request = request
        self.args = args
        self.kwargs = kwargs
        return self.dispatch(request, *args, **kwargs)
    view.view_class = cls
    view.view_initkwargs = initkwargs

    # take name and docstring from class
    update_wrapper(view, cls, updated=())

    # and possible attributes set by decorators
    # like csrf_exempt from dispatch
    update_wrapper(view, cls.dispatch, assigned=())
    return view

还可以看到，方法中实际调用了self.dispatch(request, *args, **kwargs)

self.dispatch做了什么？
直接看dispatch代码

def dispatch(self, request, *args, **kwargs):
# Try to dispatch to the right method; if a method doesn't exist,
# defer to the error handler. Also defer to the error handler if the
# request method isn't on the approved list.
if request.method.lower() in self.http_method_names:
    handler = getattr(self, request.method.lower(), self.http_method_not_allowed)
else:
    handler = self.http_method_not_allowed
return handler(request, *args, **kwargs)

通过getattr方法动态调用对应的method，如get, post等

看一个DetailView的实现方式
- 类图

2015

发表于 2016-01-01

#新年总结

##2015

换了工作
交了首付
父母搬了家
还是他妈的没摇上号

2015不管好坏都已经过去

##2016

###技术上

重新看一遍计算机网络
认真看一遍mysql核心技术
精通salt
用python构建一个类似salt的大型软件原型
去了解其自动化工具
每天坚持1小时看源码
熟悉一种js构建工具
…

###生活上

春天来了，开始坚持跑步，保持身材
出境游
开始还贷款
攒钱买车

2016来了，希望一切顺利

JS组件化开发

发表于 2015-12-04

JS 组件化开发

转载一篇写的非常好的组件化开发

http://purplebamboo.github.io/2015/03/16/javascript-component/

jinlong

Simple is better than complex

36 日志

1 分类

15 标签

GitHub E-Mail

inlfuxdb源码分析-文件结构（二）

存储数据结构

文件结构

tsm文件

Header

Blocks:

Index

inlfuxdb源码分析（一）

介绍

源码编译

clone代码

安装依赖

编译influxd

启动可执行文件

下节将从influxd这个包开始看代码

如何提高代码质量

思路

标准

反馈

参考

背景

git flow

分支

工作流

对运维的一些思考

故障前

故障中

故障后

运维开发能做啥？

对标准

对运维的日常工作

对外提供的服务

其他

open-falcon 技术分享会总结

滴滴出行

新特性

规划

美团 mt-falcon

运维、监控的一些思考

Q&A

django class based view 代码分析

JS 组件化开发

美团 `mt-falcon`