Java杂货铺

参考我做一个blog

2222-12-19T13:08:11+00:00

快速预览blog

—— 使用Jekyll

我们需要用docker来运行，因为要保持简单的环境

clone项目到本机

https://github.com/chinafzy/chinafzy.github.io

创建jekyll的docker容器

先进入到目录，然后创建docker容器，

P=4000
P2=$(expr 31729 + $P)
U=${U:-$(basename $PWD)}
JEKYLL_VERSION=3.8
docker run -it \
    --name=blog$P$U \
    -p $P:$P \
    -p $P2:$P2 \
    -v $PWD:/srv/jekyll \
    jekyll/jekyll:$JEKYLL_VERSION \
    /bin/bash -c \
        "bundle; jekyll serve --port $P -w -I -V --livereload --livereload-port $P2 --future"

P=4000，这个指定了你当前使用的端口，可以修改这个为其它值

第一次运行时候，会需要比较多的时间去下载。

打开浏览器预览

http://localhost:4000

jekyll参数说明（可忽略）

https://jekyllrb.com/docs/configuration/options/

-P, –port：指定服务端口
-w, –watch：jekyll会监听文件的修改，立刻更新
-I, –incremental：配合上面的参数，jekyll在更新的时候只更新与修改过的文件相关的内容。
这个参数会带来一个bug：新增页面不能增加到分类和标签下，需要通过命令jekyll clean && jekyll build来强制刷新。
–livereload：页面会实时监控blog的修改，发生变动时候会自动刷新页面
–livereload-port：配合上面的，实时监控的port

—— 使用Github

Fork本项目到你的Github账号下

https://github.com/chinafzy/chinafzy.github.io

修改repository的名称为USERNAME.github.io

USERNAME是你当前的Github账号名称。

访问url https://USERNAME.github.io

这个地址也可以在你的git仓库的settings中看见，如下图：

修改配置

config.yml中，修改Author部分，使用个人的配置

# Site Author
author:
  name             : "fzy"
  avatar           : "/assets/img/mny.jpg"
  bio              : "资深宅男，专业程序员."
  location         : "BJ"
  email            : 19781971@qq.com
  links:
    - label: "Email"
      icon: "fas fa-fw fa-envelope-square"
      # url: mailto:chinafzy1978@gmail.com
    - label: "Website"
      icon: "fas fa-fw fa-link"
      # url: "https://your-website.com"
    - label: "Twitter"
      icon: "fab fa-fw fa-twitter-square"
      # url: "https://twitter.com/"
    - label: "Facebook"
      icon: "fab fa-fw fa-facebook-square"
      # url: "https://facebook.com/"
    - label: "GitHub"
      icon: "fab fa-fw fa-github"
      url: "https://github.com/chinafzy"
    - label: "Instagram"
      icon: "fab fa-fw fa-instagram"
      # url: "https://instagram.com/"

123

同步/异步/select/poll/epoll

2020-05-14T00:00:00+00:00

以吃饭为案例

民以食为天

同步模式

单位食堂上了新的自助模式，经过几天的体验，很快就有人骂。领导派人调查，发现吃饭的模式大概是这样：

排一队选餐具
排一队选菜
排一队选主食
排一队付款
有时候可能还要排队等座位

食堂负责人（据说是公司x总的亲戚）晚上汇报说：我们食堂很不错，同时容纳下来八百人呢！

x总大骂：傻逼，容纳那么多人，都在排队。员工耽误时间，你挣钱慢，老子还跟着挨骂。有人告诉董事长说每天员工排队吃饭一小时半。老头子现在想砍我呢。

食堂改革，势在必行！上报领导，下利小民！

异步模式

秘书小李告诉x总，某部门程序员，3个人一组，商量好吃什么后，一个人负责拿餐具，一个选主食，一个选菜。最后一起去付账。比别人节省大半时间。

x总依稀记得大学时候的功课，哦，这个就是异步模式啊！

不是强依赖关系的工作，就不应该顺序来做。

于是在食堂门口贴出告示，推广这个先进经验。
员工吃饭时间大大缩短。

董事长大悦之余，问x总：怎么之前我没发现排队这么麻烦呢？
x总答复说：领导，因为当时都是我们几个给您拿的菜。我们就是您的分身。

x总的季度报告：我们成功的在日常管理中引入了异步模式——分身有术，让普通员工也能享受到这样的便利。

select模式

公司和食堂都是蒸蒸日上，不断壮大，菜品数量也多了，员工吃饭时间又慢慢增加，怨言也增多。董事长脾气慢慢变坏，各副总挨骂次数逐渐增加，大家得知原委后，一起压迫x总。

x总经过调查，发现员工遇到这样的情况：
下单了几个菜，隔会儿去查一下这个菜有没有来，一会儿查一下另外一个菜，都快成神经病了。

董事长听到后，呵呵一笑：
这些年轻人啊，too young too simple，哪用得着这样麻烦，问服务员就可以了。

x总解释说：
领导，您是一直在VIP包厢。
对了，领导，您说到关键点了，我们给每个员工建立VIP服务。

董事长也马上明白了：对对对。
不过又马上迷糊了：你要这样搞，我们食堂得增加多少包厢？多少服务人员？

x总于是解释：
领导，咱们是科技公司，用科技手段来做这个：VIP通道点菜。

（以下的描述比对JDK的java.nio.channels.Selector，可以忽略括号内的技术内容）
食堂提供点菜窗口（Service），员工有个点菜器（Selector），这个就是我们给员工提供的食堂VIP服务。
员工找到点菜窗口，建立服务请求（SocketChannel#connect()），再将这次的服务注册到点菜器里面（SocketChannel#register）。
从绑定后开始，员工可以随时查询点菜器（Selector#select()），每次会返回0到若干个查询结果（SelectionKey），每个查询结果里面包含服务状态和绑定的服务窗口。

有这些服务状态：

连接成功(SelectionKey#OP_CONNECT)，
可以接受下单(SelectionKey#OP_WRITE)，员工可以通过绑定的窗口开始下单点菜
菜已经准备好(SelectionKey#OP_READ)，员工可以从绑定的窗口拿菜

董事长再度大悦，让x总汇报先进经验。

x总说，我们成功的将先进的select模式引入到了我们的日常管理，彻底改变了我们的工作方式。

select模式——一个工具完成全部的交互衔接管理。

poll

增加了食堂的流量后，后厨的压力增大，于是改造成先进的select模式。

也会有点菜器，大体上与员工的差不多，主要的差别在于：

服务通道是由员工发起的，
后厨只要监听几个窗口就可以了

但是在长时间使用后，发现后厨的订单量非常大，点菜器的处理效率跟不上。于是在这个基础上做了升级，点菜器进入到后厨的核心部分，高优先级；同时优化了结构算法。

年底汇报，x总把这个技术提升换了个新名称poll，再次夺得年终述职头彩。

BTW：员工就餐的流程，因为单量不大，流程改进的意义不大了。即使一个部门百十人统一订餐，也就产生几百份菜的订餐。

epoll

时间继续前进，公司也在前进，员工数增加，食堂的服务量也在飞速增长。原有的工作流程再次体现出来不足，具体来说，流程本身的执行成本占据了比较多的工作时间。

受启发于之前的流程改进，x总意识到：
在高流量下，工作重点应该倾向于流程控制

于是他决定由流水线来作为控制者，具有最高权限：

首先将操作分为内部操作和外部操作：
- 内部操作就是厨师们的工作，例如清洗原料，做菜，这些只是在厨房内部处理的事情
- 涉外操作是要跟外部发生来回传递的工作，例如接订单、回订单、找库房要原材料……
  在涉外操作发生时候，是不可能立刻等到结果的
一次请求处理过程，形成一个流程单，将流程单放到流水线上，
在涉外操作发生后，结果返回之前，流水线会立刻将流水单挂起，并且打上标记。然后去处理别的流水单。
当涉外操作等到外部响应的时候，会立刻给

利用AWK处理日志

2020-05-06T08:27:11+00:00

前言

大数据的功能自然比awk强大很多，但是它的工作流程过于漫长，awk的快捷灵活在部分情况下更合适：

线上的紧急故障排查：这个时候肯定来不及在大数据里面慢慢折腾
新业务分析：有时候新业务的数据不一定来得及进大数据

学好awk，对于运维和高级后端开发来说都非常必要。

本文档结合实际工作里面的案例，讲述如何使用AWK来进行日志做性能分析/线上排障和业务分析。

我们线上的nginx（见附录）是以 " |# " 来分隔字段的，主要字段有：

log_format  main 
  '$remote_addr |# $remote_user |# $year-$month-$day $hour:$minute:$second |# $request |# '
  '$status |# $request_time |# $body_bytes_sent |# $http_referer |# $http_user_agent |# $http_x_forwarded_for |# '
  '$http_host |# $upstream_addr |# $upstream_status |# $upstream_response_time |# $scheme |# $content_type';

$remote_addr：来源IP
$http_x_forwarded_for：如果请求是经过了反向代理，这个字段解析原始的来源IP
$year-$month-$day $hour:$minute:$second：访问时间
$request：请求的内容，URI、方法(POST/GET…)、协议版本
$status：返回的状态码
$request_time：【重要】请求的全部处理时间（包括了网络传输）
$body_bytes_sent：返回的响应体大小
$upstream_response_time：【重要】nginx后端服务器的响应时间
$upstream_status：nginx后端服务的响应状态码
$upstream_addr：nginx后端服务器的地址端口

这个日志也是非常有实用价值的。

【业务分析】漏斗分析

开席先来个硬菜。

漏斗分析是新业务分析的非常有用的一个手段，尤其是对于页面交互设计来说，可以看到我们的每个步骤的流失/留存/转换。
比如我们做了一个拉新活动，有3个页面：起始页 -> 抽奖页 -> 提交简单注册信息，我们会关注用户在哪一步流失了。

funnel.awk会针对用户访问多个location的情况进行过滤，分析出来每一步的留存率

# awk -f funnel.awk -v v_locs="loc1;loc2;loc3" nginx1.log nginx2.log ...

function f_locIdx(loc, _i) {
  for (_i = 1; _i <= lsize; _i++) {
    if (loc ~ locs[_i]) return _i;
  }

  return 0
}

# 获取一组用户行为的traceid，这里使用$request里面的udid参数来充当
function f_getTid(_arr1, _arr2) {
  split($4, _arr1, "udid=")
  if (!_arr1[2]) {
    printf "bad request without udid: %s \n", $4 >> log_file
    return;
  }

  split(_arr1[2], _arr2, "&")

  return _arr2[1]
}

BEGIN {
  FS = " [|]# "

  if (!v_locs) {
    print "需要传入参数 v_locs " > "/dev/stderr"
    exit 111
  }
  split(v_locs, locs, "[;,]")
  lsize = length(locs)

  # 使用 -v v_log_file=logfile 将调试信息打印到文件中
  #  此参数设置为 off 将关闭打印
  #  默认将打印到 /dev/stderr 中，
  log_file = !v_log_file \
    ? "/dev/stderr" \
    : v_log_file == "off" \ 
      ? "/dev/null" \
      : v_log_file
}

{
  locIdx = f_locIdx($4)
  if (locIdx < 1) next;

  tid = f_getTid()
  if (!tid) next;

  # 记录这个tid+location的访问
  rs[tid, locIdx]++
  if (locIdx == 1) {
    # 记录第一步访问的tid
    step1[tid]
  }
}

END {
  for (tid in step1) {
    for (i = 1; i <= lsize; i++) {
      if (!rs[tid, i]) continue;

      counts[i]++;
    }
  }

  for (i = 1; i <= lsize; i++) {
    printf "%10s %s \n", sprintf("%'d", counts[i]), i == 1 ? "" : ((counts[i] * 100 / counts[i - 1]) "%")
  }
}

这个脚本的原理是：

首先为一组行为指定一个trace_id（简称tid），作为行为跟踪。范例里面用udid来模拟，不是很严谨。
记录每个tid在location下的访问记录
记录下来，每个曾经访问过step1的tid
最后根据step1的访问记录，逐步计算后续步骤的留存

输出结果是

第一列：每个步骤的发生次数，基于trace_id的unique统计
第二列：留存率百分百

使用范例：

cat access.log | \
  head -1000000 | \
  awk \
    -f funnel.awk \
    -v v_locs="appOpen.action;updateToken.action;encryptedHomePage.action"

切割access.log文件

如果日志文件比较大，将其按照小时或更小的时间单位来切割。
某些老旧的日志系统，改造比较麻烦，就可以用这样的方式来处理。

split-by-hour.awk

# awk -f split-by-hour.awk access.log
# 用字符串 " |# " 来切割字段
BEGIN { FS = " [|]# "}

{
  # 切割日期时间，获取hour_minute_second
  split($3, datetime, " ")
  split(datatime[2], hms, ":")

  print $0 >> hms[1]".log"
}

实用技巧：在AWK文件的开始加上注释，说明文件的使用方式。比较复杂的业务，还要加上备注说明。

摘取部分日志

假设我们摘取早高峰（7点8点的日志）

select-timerange.awk

# awk -f select-timerange.awk access.log
BEGIN { FS = " [|]# "}

{
  # 切割日期时间，获取hour_minute_second
  split($3, datetime, " ")
  split(datatime[2], hms, ":")

  if (hms[1] > 8) exit

  if (hms[1] < 7) next

  print $0;
}

实用技巧：AWK永远要优先考虑退出处理 exit。
对于有几千万数据的日志来说，尽早完成工作，退出处理，是必须的。

实用技巧：exit可以带一个参数，作为AWK运行后的shell返回值。

$ awk 'BEGIN { exit 111 }'; echo $?
111

【线上故障】跟踪响应慢的请求

对于线上系统来说：慢就是错。
没有任何理由，响应慢，用户感受就差，扯什么都没用。

因此，跟踪慢请求，是最基本的一个工作。

一般我们是用这个命令来做：tail -f access.log | awk -f select-slow.awk | tee slow.log

tail -f access.log，将实时跟进线上的日志
awk -f select-slow.awk，将过滤选择比较大的请求
tee slow.log，将把输入的内容同时发送到控制台和文件。
这个是一个非常有实用价值的命令。与此类似的方式是开俩个命令，一个直接输入到文件，另外一个tail -f这个文件。

# awk -f select select-slow.awk access.log
# awk -f select -v v_second=0.3 select-slow.awk access.log

BEGIN {
  FS = " [|]# "
  # 使用参数v_ms来指定最小的时间，默认值是0.1，也就是100毫秒
  second = v_second ? v_second : 0.1
  printf "选择响应时间 >= %s 的请求\n\n", ms > "/dev/stderr"
}

($6 >= second) {
  print $0
}

上面这个awk将选择响应时间在一定值（默认0.1秒）之上的请求。

实用技巧：AWK可以通过传入参数的对部分关键值进行灵活控制。

实用技巧：AWK可以往 /dev/stderr 打印输出调试语句。

【线上故障】跟踪执行慢/网络传输慢的请求

在前一案例的基础上，将过滤条件修改一下，就可以做到其它效果。

待修改代码

($6 >= second) {
 print $0
}

跟踪：执行慢
字段14$upstream_response_time代表的是后端服务器的执行时间，

($14 >= second) {
print $0
}

跟踪：网络传输慢
$request_time - $upstream_response_time就是网络传输的时间

($6 - $14 >= second) {
print $0
}

【线上故障】分析网络慢的请求

有些情况下，移动客户端（4G/3G网络) + 较大的响应体，就会产生比较多的网络消耗，拖累整体的响应时间。这个是需要定时做查询分析的，如果没有大数据，AWK也很方便。

分析网络传输和数据大小的关系：ana-network.awk

# awk -f ana-network.awk access.log
# awk -f ana-network.awk access.log -v 
function join(arr, sep, rst, i) {
  for (i = 1; i <= length(arr); i++)
    rst = rst (i > 1 ? sep : "") arr[i]

  return rst
}

function idx(sizes, size, i) {
  for (i in sizes)
    if (sizes[i] >= size)
      return i;

  return i;
}

BEGIN {
  FS = " [|]# "
  split(v_sizes ? v_sizes : "1024 2048 4196", sizes, "[ ;,]")

  printf "将使用这些大小区间来统计响应时间: %s \n\n", join(sizes, ",")  > "/dev/stderr"
}

{
  second = $6 - $14
  sizeIdx = idx(sizes, $7)

  if (maxTimes[sizeIdx] < second)
    maxTimes[sizeIdx] = second
  if (minTimex[sizeIdx] && (minTimes[sizeIdx] > second))
    minTimes[sizeIdx] = second

  counts[sizeIdx]++
  sums[sizeIdx] += second
}

END {
  _format = "%9s %9s %9s %9s %14s \n"
  printf _format, "size", "count", "max", "min", "avg"
  for (i = 1; i <= length(sizes) + 1; i++)
    printf _format,
      i <= length(sizes) ? " <= "sizes[i] : " > "sizes[i - 1],
      counts[i] ? counts[i] : 0,
      maxTimes[i] ? maxTimes[i] : 0,
      minTimes[i] ? minTime[i] : 0,
      counts[i] ? sums[i] / counts[i] : 0
}

线上日志大文件处理的注意事项

一定要先测试 一定要先测试 一定要先测试

这个是个人的经验教训：线上AWK处理大文件，一定要先测试。

线上的机器，如果原本有一定的压力，一个大磁盘操作就可能是压倒骆驼的最后那根稻草。awk本身倒不是很严重，因为它最多只能占据一核CPU。cat带来的磁盘压力更可怕，在极端环境下，连锁反应就崩溃了。

比如这样： cat access.log | head -10000 | awk -f ana.awk | more

cat来获取文件，或zcat获取压缩文件
head -10000获取前面的若干行，这个在测试阶段必须要加，哪怕是写一百万一个亿，也比不写的好。
最后的这个more是为了避免输出太多，到时候ctrl + c都来不及。
个人非常熟练的情况下，这个环节可以忽略。
使用less效果更好，因为它会进入到交互界面，支持查询。

附录

access.log

这个是我们的部分nginx访问日志

255.131.183 |# - |# 2020-05-06 00:06:01 |# GET /bus/line!encRefreshLineDetail.action?stats_act=auto_refresh&refreshModule=&sign=MflpWbAMMtOhC%2B%2FLeOX8eA%3D%3D&language=1&cityId=014&transmission=&lineNo=M3853&phoneBrand=OPPO&gps_ts=1588688183510&lchsrc=icon&system_push_open=1&lat=22.545575&deviceType=OPPO+R11st&geo_type=gcj&o1=8b12a74508a73536d65afce26d88b16c107b2fc2&targetStationLng=113.96663137225858&cryptoSign=2d062170d1f4f8f450f02d0b27a3aa3a&lng=114.067892&first_src=app_oppo_store&vc=176&isNewLineDetail=1&gpstype=gcj&geo_lt=2&last_src=app_oppo_store&sstate=3&wifi_open=1&screenDensity=3.0&needAds=false&flpolicy=1&astate=1&bdStnLng=113.96009695847908&screenWidth=1080&cshow=other&nw=WIFI&stats_referer=searchHistory&lineName=M385&AndroidID=6fecf31956be2c36&mac=d4%3A1a%3A3f%3A5a%3Ab3%3A3d&bdStnLat=22.563166913371045&persistTravelId=&stationName=%E9%BE%99%E4%BA%95%E5%B7%A5%E4%B8%9A%E5%8C%BA&udid=9889906c-3280-49b0-9e0e-d26204d3fdfd&targetStationLat=22.568996038396172&direction=0&targetOrder=4&push_open=1&sv=8.1.0&geo_lac=550.0&screenHeight=1962&lineId=0755-M3853-0&showModule=1%2C1%3B2%2C1%3B3%2C1%3B4%2C1%3B&userAgent=Mozilla%2F5.0+%28Linux%3B+Android+8.1.0%3B+OPPO+R11st+Build%2FOPM1.171019.011%3B+wv%29+AppleWebKit%2F537.36+%28KHTML%2C+like+Gecko%29+Version%2F4.0+Chrome%2F62.0.3202.84+Mobile+Safari%2F537.36&userId=unknown&filter=1&paramsMakeUp=is&s=android&geo_lng=114.067892&geo_lat=22.545575&v=3.91.0&imei=868639038438756&stats_order=1-2&timeStamp=1588694762021&cryptoSignStr=c1ec5963f63c1608fadc1775284b58b5&dns_error=3 HTTP/1.1 |# 200 |# 0.040 |# 2676 |# - |# Dalvik/2.1.0 (Linux; U; Android 8.1.0; OPPO R11st Build/OPM1.171019.011) |# 120.229.52.6 |# api.chelaile.net.cn |# 172.17.17.49:8090 |# 200 |# 0.040 |# 158869476169224eca7f229150e5b1bd |# https |# -
17.16.121 |# - |# 2020-05-06 00:06:01 |# GET /bus/line!lineDetail.action?lineId=020-00601-1&direction=1&s=h5&v=3.3.19&sign=1&cityId=040&gpstype=gcj HTTP/1.1 |# 200 |# 0.020 |# 3883 |# http://web.chelaile.net.cn/ch5/index.html?utm_source=webapp_meizu_map&src=webapp_meizu_map&utm_medium=menu&hideFooter=1&gpstype=gcj&cityName=%E5%B9%BF%E5%B7%9E&cityId=040&supportSubway=1&cityVersion=0&lat=23.079135&lng=113.233398 |# Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36 |# - |# api.chelaile.net.cn |# 172.17.16.150:8090 |# 200 |# 0.020 |# 158869476173176148dfc5dadced730f |# http |# -
40.217.253 |# - |# 2020-05-06 00:06:01 |# GET /api/bus/line!encryptedLineDetail.action?s=h5&wxs=wx_app&sign=1&v=3.8.156&src=weixinapp_cx&ctm_mp=mp_wx&cityId=040&userId=okBHq0NX9JkqLhp6NllM4maiohW4&h5Id=okBHq0NX9JkqLhp6NllM4maiohW4&lat=23.075265&lng=113.28792&geo_lat=23.075265&geo_lng=113.28792&gpstype=wgs&isNewCity=0&lineId=002031512162&targetOrder=16&cryptoSign=4debff6219f5a201e5c73f4f38681c7c HTTP/1.1 |# 200 |# 0.024 |# 10260 |# https://servicewechat.com/wx71d589ea01ce3321/379/page-frame.html |# Mozilla/5.0 (Linux; Android 9; Redmi K20 Pro Build/PKQ1.181121.001; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/74.0.3729.136 Mobile Safari/537.36 MicroMessenger/7.0.13.1640(0x27000D39) Process/appbrand4 NetType/4G Language/zh_CN ABI/arm64 WeChat/arm64 |# - |# web.chelaile.net.cn |# 172.17.16.19:80 |# 200 |# 0.024 |# https |# text
17.16.19 |# - |# 2020-05-06 00:06:01 |# GET /basesearch/client/clientSearch.action?s=h5&wxs=wx_app&sign=1&v=3.8.156&src=weixinapp_cx&ctm_mp=mp_wx&cityId=040&userId=okBHq0M7RNkwqFrLtia96iE16qlk&h5Id=okBHq0M7RNkwqFrLtia96iE16qlk&unionId=oSpTTjt3ei-o_zY3APX86wqPf1oA&lat=23.152059&lng=113.217306&geo_lat=23.152059&geo_lng=113.217306&gpstype=wgs&key=%E6%A7%8E%E5%A4%B4 HTTP/1.1 |# 200 |# 0.121 |# 807 |# https://servicewechat.com/wx71d589ea01ce3321/379/page-frame.html |# Mozilla/5.0 (Linux; Android 9; PAR-AL00 Build/HUAWEIPAR-AL00; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/79.0.3945.116 Mobile Safari/537.36 MicroMessenger/7.0.13.1640(0x27000D39) Process/appbrand2 NetType/4G Language/zh_CN ABI/arm64 WeChat/arm64 |# - |# api.chelaile.net.cn |# 172.17.16.69:9397 |# 200 |# 0.121 |# 15886947616688c4aaf5c89c56fc9117 |# http |# application/json
85.198.3 |# - |# 2020-05-06 00:06:01 |# GET /bus/stop!versionUpdtControl.action?mac=&userId=&geo_lng=106.776500&timestamp=1588694761753&gps_ts=1588694758836&accountId=32979580&sstate=3&appStartId=1588694752593_1717703&userAgent=Mozilla/5.0%20(iPhone;%20CPU%20iPhone%20OS%2013_4_1%20like%20Mac%20OS%20X)%20AppleWebKit/605.1.15%20(KHTML,%20like%20Gecko)%20Mobile/15E148&vc=15902&gps_speed=-1&sv=13.4.1&geo_lat=26.570035&screenWidth=1125&imsi=46000&geo_lac=65.000000&localCityId=083&secret=6b6adab1a48b41eeb24cd5bbfe71ff78&gpsAccuracy=65.000000&deviceType=iPhoneX&idfa=C5C7308F-6878-4747-8F6B-9FF8EFF66737&idfv=58D2FB5E-AE56-4876-AA7D-060829C45FAF&screenHeight=2436&localIdCreateTime=1588405573863&rnver=5.90.2.16&sign=uZKiBqWIaewibCdqc78IUQ==&s=IOS&cityId=003&dpi=3&push_open=1&astate=1&wifi_open=1&locState=3&gps_accuracy=65&v=5.90.2&geo_type=wgs&nw=WiFi&language=1&vendor=apple&lchsrc=icon&udid=110b389dd2b86d5aae8ae31d145584047217a462&locOn=1 HTTP/1.1 |# 200 |# 0.003 |# 85 |# - |# lite/5.90.2 (iPhone; iOS 13.4.1; Scale/3.00) |# - |# api.chelaile.net.cn |# 172.17.17.84:8090 |# 200 |# 0.003 |# 1588694761796794d759e51cd04eaddf |# https |# -
202.39.142 |# - |# 2020-05-06 00:06:01 |# GET /bus/reminder!updateToken.action?last_src=app_oppo_store&s=android&push_open=1&token=73beb18f06338d74a8c7acf1586a4a5a&userId=unknown&astate=1&vc=176&sv=6.0.1&v=3.91.0&imei=864412039047636&system_push_open=1&udid=1156782f-7bae-4443-a3a6-ab73dcbd5be5&cityId=094&sign=MflpWbAMMtMTGBI10KL38g%3D%3D&wifi_open=1&mac=98%3A6f%3A60%3Acd%3A20%3Aa5&deviceType=OPPO+R9sk&lchsrc=icon&nw=WIFI&sstate=3&paramsMakeUp=is&AndroidID=b47a3dc850c07564&phoneBrand=OPPO&language=1&first_src=app_oppo_store&tokenType=0 HTTP/1.1 |# 200 |# 0.001 |# 77 |# - |# Dalvik/2.1.0 (Linux; U; Android 6.0.1; OPPO R9sk Build/MMB29M) |# - |# api.chelaile.net.cn |# 172.17.17.18:9090 |# 200 |# 0.001 |# 158869476181379ce549a22e8a36d369 |# https |# -
29.84.125 |# - |# 2020-05-06 00:06:01 |# GET /wow/user!query2.action?last_src=app_360_sj&s=android&push_open=1&userId=unknown&geo_lt=4&geo_lat=38.141958&astate=1&vc=162&sv=7.1.1&v=3.86.2&secret=62c0accde2f94d8da5f4d97e26a10a5f&imei=99000788013541&oaIdDeviceCode=1008611&system_push_open=1&udid=5a82f277-2495-485d-911f-c10c5a215523&oaIdDeviceSupport=notSupport&cityId=053&sign=MflpWbAMMtP1OS32RR%2FzsA%3D%3D&geo_type=gcj&deviceType=VCR-A0&mac=54%3Adc%3A1d%3Ab6%3Ae1%3A14&wifi_open=1&lchsrc=icon&sstate=3&nw=WIFI&paramsMakeUp=is&AndroidID=58af64db77839869&geo_lac=100.0&phoneBrand=Coolpad&accountId=86987530&oaId=unknown&language=1&first_src=app_qq_sj&geo_lng=114.586532 HTTP/1.1 |# 200 |# 0.022 |# 582 |# - |# Dalvik/2.1.0 (Linux; U; Android 7.1.1; VCR-A0 Build/VCRSCN00X1000MPX1711140) |# - |# api.chelaile.net.cn |# 172.17.17.100:9070 |# 200 |# 0.022 |# 158869476180911f1c2bb8903b917cff |# https |# -
123.206.62 |# - |# 2020-05-06 00:06:01 |# GET /sensors?project=default&token=fae3b5aa4801542a38bad43ba8f4f34d631ac3789c5475a4b5e065def990c68d&data=eyJkaXN0aW5jdF9pZCI6Im9rQkhxMEl3Qjlfb0ljbHVOektrNzhzVUc3eDQiLCJsaWIiOnsiJGxpYiI6Ik1pbmlQcm9ncmFtIiwiJGxpYl9tZXRob2QiOiJjb2RlIiwiJGxpYl92ZXJzaW9uIjoiMC42In0sInByb3BlcnRpZXMiOnsiJGxpYiI6Ik1pbmlQcm9ncmFtIiwiJGxpYl92ZXJzaW9uIjoiMC42IiwiJHVzZXJfYWdlbnQiOiJTZW5zb3JzQW5hbHl0aWNzIE1QIFNESyIsIiRuZXR3b3JrX3R5cGUiOiJ3aWZpIiwiJG1vZGVsIjoiaVBob25lIDc8aVBob25lOSwxPiIsIiRzY3JlZW5fd2lkdGgiOjM3NSwiJHNjcmVlbl9oZWlnaHQiOjYwMywiJG9zIjoiaU9TIiwiJG9zX3ZlcnNpb24iOiIxMi40LjEiLCJhcHBfbmFtZSI6Iui9puadpeS6hueyvuWHhuWunuaXtuWFrOS6pCIsImFwcF92ZXJzaW9uIjoiMy44LjE1NiIsImN1clBhZ2UiOiJob21lIiwiZGVzY3JpYiI6ImhvbWUiLCJzcmMiOiJ3ZWl4aW5hcHBfY3giLCJ1c2VyVHlwZSI6IndlY2hhdF9tcCIsInBsYXRmb3JtIjoiaW9zIiwiY2l0eSI6Iua3seWcsyIsImdlb19sbmciOiIxMTMuODY5MjE2OTE4OTQ1MzEiLCJnZW9fbGF0IjoiMjIuNTgzNDE5Nzk5ODA0Njg4IiwidXNlcklkIjoib2tCSHEwSXdCOV9vSWNsdU56S2s3OHNVRzd4NCIsIiRpc19maXJzdF9kYXkiOmZhbHNlfSwidHlwZSI6InRyYWNrIiwiZXZlbnQiOiJXRUNIQVRfTVBfUEFHRSIsIl9ub2NhY2hlIjoiMzM0MTQ4ODMzMTA0MyJ9 HTTP/1.1 |# 200 |# 0.001 |# 31 |# https://servicewechat.com/wx71d589ea01ce3321/379/page-frame.html |# Mozilla/5.0 (iPhone; CPU iPhone OS 12_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 MicroMessenger/7.0.12(0x17000c2d) NetType/WIFI Language/zh_CN |# - |# web.chelaile.net.cn |# 172.17.17.73:8106 |# 200 |# 0.001 |# https |# application/json
230.99.30 |# - |# 2020-05-06 00:06:01 |# GET /bus/reminder!updateToken.action?last_src=app_oppo_store&s=android&push_open=1&token=23cc4fe44ab8c81ccc5a5abbf0cbbe8f&userId=unknown&astate=1&vc=176&sv=6.0.1&v=3.91.0&secret=7a8236af24cc47ecb1fd84d566648d2a&imei=864315038933153&system_push_open=1&udid=91b7d1d2-5ef7-480b-add6-525eeff7748f&cityId=040&sign=MflpWbAMMtMkDPmv7pLXxA%3D%3D&wifi_open=1&mac=d4%3A50%3A3f%3A50%3A0e%3Add&deviceType=OPPO+R9sk&lchsrc=icon&nw=WIFI&sstate=3&paramsMakeUp=is&AndroidID=fcfa1a1616330e7&accountId=58143812&phoneBrand=OPPO&language=1&first_src=app_oppo_store&tokenType=0 HTTP/1.1 |# 200 |# 0.001 |# 77 |# - |# Dalvik/2.1.0 (Linux; U; Android 6.0.1; OPPO R9sk Build/MMB29M) |# - |# api.chelaile.net.cn |# 172.17.17.103:9090 |# 200 |# 0.001 |# 15886947618392e5366b12e672bdeab2 |# https |# -
96.118.28 |# - |# 2020-05-06 00:06:01 |# GET /bus/reminder!updateToken.action?last_src=app_oppo_store&s=android&push_open=1&token=01f582fb46ad1e9bd47c2eabf93f42c7&userId=unknown&astate=1&vc=175&sv=6.0.1&v=3.90.4&secret=8e38bc377a2d47cb8d2964f0a7ba80ea&imei=866491036515611&system_push_open=1&udid=741f2e45-5624-4e86-8364-0c44025231a5&cityId=019&sign=MflpWbAMMtM95KYtWgrN6Q%3D%3D&wifi_open=0&mac=30%3A84%3A54%3A6c%3A58%3A17&deviceType=OPPO+A57&lchsrc=icon&nw=MOBILE_LTE&sstate=3&paramsMakeUp=is&AndroidID=91b826d010703913&accountId=133077807&phoneBrand=OPPO&language=1&first_src=app_oppo_store&tokenType=0 HTTP/1.1 |# 200 |# 0.002 |# 77 |# - |# Dalvik/2.1.0 (Linux; U; Android 6.0.1; OPPO A57 Build/MMB29M) |# - |# api.chelaile.net.cn |# 172.17.17.18:9090 |# 200 |# 0.002 |# 1588694761847388a64bb9e328cee8d1 |# https |# -

HashMap的死锁（JDK7)

2020-02-01T00:00:00+00:00

说明

早期JDK的HashMap，在多线程下，会出现各种问题：

数据掉了
数据删了又回来了
死锁

这里分析死锁产生的原理（或者说可能性）之一

源码

http://hg.openjdk.java.net/icedtea/jdk7/jdk/file/tip/src/share/classes/java/util/HashMap.java

我们需要关注的是函数transfer下的while循环（行4-13）

void transfer(Entry[] newTable, boolean rehash) {
  int newCapacity = newTable.length;
  for (Entry<K,V> e : table) {
    while(null != e) {
      Entry<K,V> next = e.next;
      if (rehash) {
        e.hash = null == e.key ? 0 : hash(e.key);
      }
      int i = indexFor(e.hash, newCapacity);
      e.next = newTable[i];
      newTable[i] = e;
      e = next;
    }
  }
}

它的主要逻辑：

获取一个节点，
计算节点的hash值，以及对应在新数组中的slot位置
查看slot位置上，是否已经有节点链：
- 如果没有，直接将新节点放入；
- 如果原来的位置上已有节点，将旧节点附加在新节点的后面，新节点成为链条的头部（因此叫头插法），新节点放在slot位置上；
如果有剩余节点，继续循环

案例设定

假设有table数组长度是2，有俩个元素，key的hashCode分别是【3】和【7】。
原始的数据结构如下：

0
1   【3】-> 【7】

现在要将其transfer为长度4的数组。

正常的程序运行过程

程序逻辑认定的正常运行过程如下：

while循环第一次运行到最后

0
1 	
2
3   【3】
-- 以上是数组，以下是临时变量 --
e  =【7】

循环第二次运行到最后

0
1
2
3   【7】 -> 【3】

e = null

e = null，整体循环结束

死锁的产生

假设我们有俩个线程，同时运行了transfer操作（这个非常容易发生）。

俩个线程都完成第一个循环

俩个线程中数据结构变为：

0
1 	
2
3   【3】

e  =【7】

线程1停留在这里，线程2继续完成第二个循环，结束退出

线程2里面看见的数据结构是这样

0
1
2
3   【7】 ->【3】

e = null

根据Java内存模型，节点之间的next指向关系会影响到线程1

因此，线程1里面的数据结构就变成了：

0
1 	
2
3   【3】

e  =【7】->【3】

线程1的二次循环结束

0
1 	
2
3   【7】->【3】

e  =【3】

这个时候，e != null，还会继续循环

线程1的三次循环结束

0
1
2
3   【3】<->【7】

e = null

e = null，整体循环结束
节点【3】【7】形成相互循环

死锁的爆发

查询操作的key位于slot3上时候（例如hashCode是【11】），将产生死循环

问题分析

这个问题的根源，在于：

发生问题的key，它们在tranfer到新的数组后还位于一个slot上
链表的头插法
多线程

链表的头插法是其中的关键要素之一，这个不修改，问题就始终存在。下面是jdk7中HashMap的其它版本，这个问题依旧存在。

https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/classes/java/util/HashMap.java

Kafka Broker 出现Too many open files

2019-06-25T23:08:11+00:00

问题描述

环境

kafka server 0.10.0.1 （查看libs/kafka_2.10-0.10.0.1.jar）
5个broker
1000个partition，3份的存储
部分partition每秒数据有3000，一半以上的大概1000条
数据每条大概是100B
200个partition的数据被实时消费
使用机械硬盘

问题表现

外部无法连接

此时第一个kafka broker上的日志server.log大量出现错误

[2019-06-21 18:03:29,341] ERROR Error while accepting connection (kafka.network.Acceptor)
java.io.IOException: Too many open files
      at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
      at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422)
      at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250)
      at kafka.network.Acceptor.accept(SocketServer.scala:323)
      at kafka.network.Acceptor.run(SocketServer.scala:268)
      at java.lang.Thread.run(Thread.java:748)

查看kafka server的文件句柄lsof -p <pid>，里面有近十万的can't identify protocol
消费程序无法获取数据
到一定时候，有问题的broker可能崩溃。
重启出问题的broker后，问题解决。

排查过程

因为数据是多副本，所以考虑将问题节点下线，但是下线后遇到问题，消费程序都不能从kafka消费。

使用jstack连续多次抓取消费者Java进程，发现，

但是这时用kafka-console-consumer.sh来消费是可以。

继续排查后，发现不同的消费方式会有不同的结果（在后续版本中，这些参数混乱被纠正了）：

使用参数--zookeeper localhost:2181可以消费
使用参数--bootstrap-server localhost9092 --new-consumer的方式不可以消费

有伙伴怀疑，__consumer_offset是单点的，使用kafka-topic.sh --describe看了之后，发现的确如此，而且单点位置放置在第一个broker上，因此当第一个broker出问题后，整个kafka集群不能消费。

使用kafka-reassign-partitions.sh将__consumer_offset做三份，打散到多个broker后。问题解决。

深入分析

`__consumer_offset`单点导致的网络连接问题

`__consumer_offset`单点问题的产生

Linux下的connection leak

2019-06-25T23:08:11+00:00

给程序员小伙伴的推荐

2019-01-01T00:00:00+00:00

新年伊始，给程序员小伙伴们推荐一下后端语言技能。

第一是docker：
因为它是最有用的工具。可以很容易的在电脑上模拟各种服务器环境，实在是性能学习的必备法宝。
第二是lua：是性能的超级法宝。关键时候，能给性能带来爆炸的提升。
- lua+nginx/openresty的性能起点是几万qps，毫秒级响应，很多其他服务器的终点都达不到了。非常适合做【穿透+一定计算】的场景。
- redis+lua，能做纳秒级事务，比如秒杀这些小东西。
第三是java+设计模式/工程管理：
做小工具，java的语法有点累赘了，但是他的规范性在得到各种设计模式增强后，绝对是大工程的不二选择。
（没约束的）灵活性在工程里绝对致命的。小打小闹的做个工具/玩具，自然越灵活越好，但是代码量和功能增加，经手人来来往往，混乱不断引入，麻烦会不断突破性升级。有志于深入程序的小伙伴，一定要抓住设计模式和软件工程管理。
第四是工具级，spring boot：
所有的东西都是开箱即得，数据库、缓存、rest客户端……，在这个上面做快速开发绝对是当前最好的，而且性能还不错。
有志于互联网创业的小伙伴的不二选择，如果竞争对手搞什么php快速上线了，拿个浏览器就可以把他刷下线。

继承还是聚合，设计模式的取舍？

2019-01-01T00:00:00+00:00

从JDK的一个经典bug说起继承(inherit)的不足

JDK实现了观察者设计模式，

java.util.Observable：可被观察的对象，主要函数：
- addObserver()/deleteObserver()：增删观察者
- notifyObservers()：通知观察者数据变动
java.util.Observer：观察调用的callback，函数：
- update(Observable observable, Object obj)

假设我要做一个UI类，在内部资源内容发生变动时候，需要通知别的模块，观察者模式是最好的选择。
我们期望的代码是这样的：

class MgrView extends View {
    private Observable monitor = new Observable();
    
    public Mgr(Observer callback){
        monitor.addObserver(callback);
    }

    public void do1(Object res){
        // ... 处理业务 ...
        
        // 处理完了后发送通知 
        monitor.update(res);
    }
}

但是我们在查看JDK自带的包，发现了一个问题：
Observable中的关键代码：控制Observable是否启用的#setChanged()/#clearChanged()，可见性是protected。
因此要使用这个类，只能继承。

从概念上说：我的类的基础特性是UI View；观察者模式只是它的一个分支特性，不是根本特性。
因此，继承Observable就是一个错误的方式。

但是，JDK的观察者模式默认了是继承模式。这个给我们的使用带来了很大的麻烦。是一个完全错误的考虑。

从技术层面来看，它后续还不能把那个protected升级为public，因为这样的话，现有的子类如果有protected @Override这个方法的，就会出错了。

简单结论：何时适合做继承或者组合

从上面的例子延伸考虑：

UIView是我们的组件的主要特性，组件“是一个(IsA)”UIView
组件还有可观察的次要属性，组件“有一个(HasA)”Observable

把一个HasA的特性变成了IsA，就会让组件多出来很多莫名其妙的功能。

这个是最简单也是最基础的分辨。但是有时候可以模糊执行：
如果没有IsA，而且这个需求没有后续发展，HasA可以用IsA来冒充。

例如：要做一个临时的小工具，这个工具不是基于别的工具的基础上来做，而有“可观察”特性。这个时候，就可以直接继承Observable，也告诉使用的人，里面其他的函数别管了。

从SpringBoot的一个例子

SpringBoot里面可以很方便的配置对redis的集成，但是美中不足的是：
如果我们要同时访问多个redis，那就麻烦了。

扩展的方式在别的地方有写，这里只是讨论这个设计的得失：

一个应用，应该是有一个多个redis数据源，而不是只有一个。在spring-boot的设计中，很明显的感觉到，他把数据源的集成做成了IsA，而不是HasA。

Java Tips

2018-12-19T13:08:11+00:00

find class in jars

find . -name *.jar -maxdepth 4 -exec grep -Hlsi org.apache.util.CacheLRU.class {} \;

The type parameter V is hiding the type V

A-E, P, V

@SuppressWarnings ("hiding")

Manage Java version on macos

https://stackoverflow.com/questions/21964709/how-to-set-or-change-the-default-java-jdk-version-on-os-x

Find Installed Javas

/usr/libexec/java_home -V
Matching Java Virtual Machines (5):
0.1, x86_64:	"Java SE 10.0.1"	/Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home
8.0_172, x86_64:	"Java SE 8"	/Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home
8.0_131, x86_64:	"Java SE 8"	/Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home
8.0_65, x86_64:	"Java SE 8"	/Library/Java/JavaVirtualMachines/jdk1.8.0_65.jdk/Contents/Home
7.0_80, x86_64:	"Java SE 7"	/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home

switch java by JAVA_HOME variant

export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_172.jdk/Contents/Home

compiler识别exception

以下代码在jdk6上编译失败，7及以上ok，原因是新的编译器能识别这个实际上的异常。

public static void main(String[] args) {

    try {
        throw new RuntimeException();
    } catch (Exception e) {
        throw e;
    }
}

代理和反向代理

2018-12-18T23:08:11+00:00

和小伙伴们闲聊，代理forward proxy和反向代理reverse proxy。

最早的时候，就只有proxy的概念，但是自从反向代理reverse proxy的概念出现后，原来的proxy就修订为forward proxy。一般情况下，如果只说代理proxy，指的还是forward proxy。

下面来聊聊他们之间的差别。

以借钱为案例比喻

假设我是某个童话王国的商人，做生意需要更多资金，但是对贷款业务不熟悉，于是找个中间人帮忙跑腿。去a银行借点，b富豪借点。
这个人，我们先称为代理。

然后，在去找c银行的时候，行长说：由于风控（国家政策经济形势……以下节省十分钟演讲……），现在我们对小额贷款收缩了，办不了你这个。你要借钱，我介绍一个朋友给你认识吧，他有路子。

懂事的你自然明白：这个人实际上也是从这个银行借钱出来，再借钱给你。

但是银行不直接跟你玩，他指定了这个人做他的代理人，你只能跟这个人玩。
这个人就是银行的代理，我们暂时称他为反向代理。

从这个故事来解析

发起者，使用中介，到达目的地，这个就是 正向代理 forward proxy
目的地，把自己隐藏起来，让别人只能通过那个中介找到他，这个就是 反向代理 reverse proxy

反向代理的第一特征

对于发起者来说，这个中介是不是完全“代表”了目的地，把目的地隐藏起来了，是关键差别一。

举例来说：
童话故事里因为贷款太麻烦，存款利息又低，银行态度还特别拽，爱存不存。
然后民间出了个公司，可以存款+借贷。对于大家来说，存款利息高了，贷款利息低了，手续还特别方便。众人皆大欢喜。
突然天降灵符，说这个不安全，上天有好生之德，我要管理这个，不允许你们这样做，我要保护大家。
于是大家又只能回去接受银行的盘剥和刁难。

这个管理灵符，他隐藏并代表了被管理对象，因此是reverse proxy 。
当然灵符还会宣传：自己代表了上天的意志，代表了历史的选择，也代表了人命的利益。

反向代理的第二特征

他可能会修改请求和答复

还是以童话王国的借钱为例，如果是我们找到的代理，他一般要手续费。

但是如果是反向代理，很可能就变成这样了：

借款人要接100w；
反向代理找银行拿120w，到期还款130w；
反向代理告诉借款人利息15w，信息服务费15w，要还130w——各种名目收钱，但合同字面的利息可能就只有15%；
反向代理人还说：还有中间人好处费20w——这个是借款人自愿送给他的，所以更不是利息了；
最后贷款人拿到80w，但是要还130w。

反向代理俩头都骗，对客户端冒充服务器端，对服务器端冒充客户端。

童话王国里面的普通老百姓搞不明白一个道理：
为什么银行贷款利息那么低，但是做生意的要去借高利贷？

用IT案例来说

由于某个不能说的秘密，大家不能访问不了技术网站，通过代理来访问，这个是forward proxy。
公司为了方面大家看技术网站，搭了一个代理服务器，80端口指向stackoverflow，81端口指向github，这个就是reverse proxy
手机调试，走charless，不仅可以看见请求和答复，还可以修改，这个是reverse proxy。