做中学, 学中做

2017-07-14
tmux 简单使用指南

Tmux 的简单使用说明

工欲善其事,必先利其器

Tmux 是一个多窗口管理程序。可以让用户在一个地方管理多个终端。而不需要在不同的终端间来回切换。

在 Mac 下如何安装

直接使用 brew install tmux 就可以了,如果没有 brew,则需要先安装 brew,然后再执行上述命令。

简单使用流程

首先,需要了解 tmux 中的几个概念。session,window 以及 pane。这几者的关系如下,tmux 中可以起多个 session,每个 session 可以启动多个 window,然后每个 window 可以启动多个 pane。

这里给一个基本的流程

  1. 启动 tmux(默认会启动一个 session)
    使用 tmux 启动 tmux,使用 exit 退出 tmux,session 的命名默认是从 0 开始,一直往上加

  2. 在 session 中启动一个 window
    PREFIX c 会在当前 session 中创建一个 window, 其中 PREFIX 表示 tmux 中的命令前缀符(该条命令表示,先按下 PREFIX,然后按下 c),

  3. 在启动的 window 中创建一个 pane
    PREFIX % 竖直方向切分一个 window,PREFIX " 横向切分一个 window。这样就能够在 window 中创建 pane 了。基本的这些就够了。

  4. 如何在 session,window,pane 中进行移动
    能够创建 session,window,pane 了,接下来就是如何在 session,window,pane 间进行移动了。
    PREFIX s 会列出所有 session,然后进行具体的选择(可以上下移动光标,然后按 ENTRER 确定)
    PREFIX w 可以列出所有的 window,然后进行具体的筛选
    PREFIX n 可以切换到下一个 window
    PREFIX p 可以切换到上一个 window
    PREFIX & 可以关闭当前 window
    PREFIX o 可以在 pane 之间进行跳转
    tmux ls 会列出当前所有的 session(在非 tmux 环境下)

自定义 tmux

tmux 的配置文件可以保存在两个地方

  1. /etc/tmux.conf
  2. ~/.tmux.conf

其中 2 的优先级会更高,1 的影响面更广

接下来做什么

上面的仅仅是一个入门文档,也就是最少基本知识,接下来就是多实践。推荐一本小书《tmux productive mouse-free development》

tmux_pic.png

2017-06-20
风险不仅仅是事件发生的概率

风险不仅仅是事件发生的概率

风险可以定义为 = 事件结果对你的影响 * 事件发生的概率

风险在生活中处处存在,可能我们会想冒个险没啥关系,反正发生的概率小,而且在某些时候会有高收益/回报伴随这风险,这个时候就更有诱惑力了,总有人希望通过冒险得到高回报,但这恰恰是不可取的,是非常危险的。

Read More

2017-06-03
Streaming 程序调用 Producer.close hang 住问题追查复盘

本文作为一个问题追查过程的复盘记录,主要希望找出自己在解决问题中可以优化改进的地方。以后遇到问题,能够快速的进行定位,解决。

Read More

2017-06-01
如何在不重启 Spark Streaming 作业的情况下,增加消费的 topic

本文所有和 kafka 相关操作都基于 Direct 消费模式

在 Spark Streaming 作业中,每个作业会消费一个或多个 topic,但是这些 topic 需要在作业启动之前确定好,在作业运行中不能进行调整,之前修改了源码做到了自适应 topic partition 扩容的情况,但是无法动态调整消费的 topic。现在需要在不重启作业的情况下,动态调整消费的 topic。

Read More

2017-05-29
从源码级别分析 metric-core 的抽样算法

metric-core 是一个 java metric 库,用于统计 JVM 层面以及 服务级别 的各种 metric 信息。其中 metric-core 是其核心模块,代码量不多,总共 44 个文件,5700 行左右代码(包括注释)。算是一个很小的开源项目了。由于 metric 在所有项目中都非常重要,因此选择通读该项目,本文分析 metrci-core 中的抽样算法。

Read More

2017-05-19
Streaming 中 Receiver 相关源码分析

本文基于 spark 1.6.2
本次的源码全来自 org.apache.spark.streaming.receiver 这个 package 下,包括 BlockGenerator.scala, RateLimiter, ReceiverdBlock.scala, ReceivedBlockHandler.scala, Receiver.scala, ReceiverSupervisor.scala, ReceiverSupervisorImpl.scala

Read More

2017-05-10
Python 代码实践小结

最近写了较多的 Python 脚本,将最近自己写的脚本进行一个总结,其中有些是 Python 独有的,有些是所有程序设计中共有的:

  1. 考虑使用 Logger(logger 怎么配置,需要输出哪些信息 – 可以反向考虑,自己看到这个 logger 的时候想了解什么信息)
  2. 传递的数据结构如何考虑(是否对调用方有先验知识的要求,比如返回一个 Tuple,则需要用户了解 tuple 中元素的顺序,这样情况是否应该进行封装;),数据结构定义清楚了,很多东西也就清楚了。
  3. 如何操作数据库(可以学习 sqlalchemy,包括 core 和 orm 两种 api)
  4. 异常如何处理(异常应该分开捕获 – 可以清楚的知道什么情况下导致的,异常之后应该打印日志说明出现什么问题,如果情况恶劣需要进行异常再次抛出或者报警)
  5. 所有获取资源的地方都应该做 check(a. 没有获取到会怎么办;b.获取到异常的怎么办)
  6. 所有操作资源的地方都应该检查是否操作成功
  7. 每个函数都应该简短,如果函数过长应该进行拆分(有个建议值,函数包含的行数应该在 20-30 行之间,具体按照这个规范做过一次之后就会发现这样真好)
  8. 使用 class 之后,考虑重构 __str__ 函数,用户打印输出,如果对象放到 collection 中之后,需要实现 __repr__ 函数,用于打印整个 collection 的时候,直观显示(如果不实现 __str__,会调用 __repr__)
  9. 如果有些资源会发生变化,可以单独抽取出来,做成函数,这样后续调用就可以不用改变了

上述总结肯定有片面的地方,也有不全的地方,欢迎指出

Read More

2017-04-15
从现在开始写作

这里的写作不特指写长篇大论的文章

为什么要写作

写作是了帮助自己更好的思考,提高自己的效率。

首先,每个人同一时刻能记住的东西有限,而做一件事情可能需要考虑的条件往往会比较多,将所有的情况写到一张纸上,就能在需要的时候看到自己需要的条件。相信每个人都有这样的体验:做数学题的时候,将所有的已知条件,或者自己推导出来的结论写到草稿纸上,往往能更快的解出这道题目。这也是写作帮助自己思考的一个直接。

其次,我遇到过这种情况,自己想着是这么回事,可是写下来的时候,发现无从下笔,根本写不出来,写出来之后,也很难向别人清楚、准确的表达自己的意思。这归根结底还是没有思考清楚导致的,而写作可以帮助我整理自己的思路。

然后,当过客服的人肯定有一个体会,客服非常耗时间,而这些客服的问题大部分是差不多的,一对一的客服是非常低效的,就算在群组里面进行客服,其实很多后来遇到同样问题的人也是不看群历史记录(或者不知道以前有人遇到过类似的问题)的。这种情况下,虽然文档不是最优解,但能够省出自己足够多的时间,实际上这是一件杠杆率非常高(产出投入比高)的事件。

Read More

2017-02-16
Spark Streaming 统一在每分钟的 00 秒消费 Kafka 数据的问题解决

现象

一批 Spark Streaming 会统一在每分钟的 00 秒开始消费 kafka 数据

Read More

2017-01-15
Spark Streaming 往 HDFS 追加 LZO 文件

需求

将数据从 Kafka 同步到 Hive,并且目标格式希望是 lzo。我们通过 Spark Streaming 做这件事,将文件写成 lzo 格式,并且添加索引。

Read More