原先的博客由于腾讯云的服务器到期了，续费发现挺贵的就停了。 后面觉得还是得有个地方记录一下生活。 之前使用的是halo，用了挺长时间的，后面想想自己的博客也不需要那么多功能，一个静态的就足够了。 所以就换到了hugo，用的主题是PageMod,挺符合我的直男审美。 搭建起来挺简单的，就是需要安装hugo和主题，然后配置一下，然后就可以运行了。 最后是在cloudflare上部署的，很简单。默认的hugo版本比较旧，需要在环境变量里指定下版本号。HUGO_VERSION: 0.139.2. 部署指南 后续慢慢把之前的博客迁移过来。
注 请求消息服务标识符和肯定响应消息标识符之间存在一一对应关系，SI的bit第6位表示服务类型。所有请求消息中SI bit6=0。所有肯定响应消息中 SI bit6=1。 请求hex 请求binary 肯定响应hex 肯定响应binary 0x10 0010000 0x50 1010000 0xBA 10111010 0xFA 11111010 ReadDataByPeriodicidentifier（通过周期标识符读取数据）服务的周期性数据响应消息除外(0x2A)，首先回复一个0x6A消息,之后会周期性回复periodicDataIdentifier+dataRecord[] Service Identifier(SI) Service type(bit6) 定义 0x10–0x3E service requests ISO14229-1 0x3F Not applicable 保留 0x50–0x7E positive service responses ISO14229-1 0x7F Negative response service identifier ISO14229-1 0x80–0x82 Not applicable 保留 0x83–0x88 service requests ISO14229-1 0x89–0xB9 Not applicable 保留 0xBA–0xBE Service requests 厂商自定义 0xBF–0xC2 Not applicable 保留 0xC3–0xC8 positive service responses ISO14229-1 0xC9–0xF9 Not applicable 保留 0xFA–0xFE Positive service responses 厂商自定义 0xFF Not applicable 保留
前置知识 内部值：从ECU收到的响应信息中提取出的结果 物理值：内部值转换到诊断仪或其他设备上人类可读的值 正向计算：内部值–>物理值 反向计算：物理值–>内部值 根据compu-method的标签情况，计算内部值->物理值转换的规则 COMPU-METHOD internal -> physical (response) use physical -> internal (request) use 只有 COMPU-INTERNAL-TO-PHYS COMPU-INTERNAL-TO-PHYS COMPU-INTERNAL-TO-PHYS 逆运算 COMPU-INTERNAL-TO-PHYS 、 COMPU-PHYS-TO-INTERNAL 都有 COMPU-INTERNAL-TO-PHYS COMPU-PHYS-TO-INTERNAL 只有 COMPU-PHYS-TO-INTERNAL COMPU-PHYS-TO-INTERNAL 逆运算 COMPU-PHYS-TO-INTERNAL COMPU-METHOD 一共有8种类型: IDENTICAL, LINEAR, SCALE-LINEAR, TEXTTABLE, COMPUCODE, TAB-INTP, RAT-FUNC , SCALE-RAT-FUNC。使用<CATEGORY>(必填)属性定义 1.IDENTICAL 它只传递输入值，因此内部值和物理值是相同的。即$f(x)=x$ 对于这种类型，不允许使用数据对象 COMPU-INTERNAL-TO-PHYS 和 COMPU-PHYS-TOINTERNAL。 如果编码类型（在 DIAG-CODED-TYPE 的 BASE-TYPE-ENCODING 处）为 A_ASCIISTRING 或 A_UTF8STRING，则在解码或编码过程中应隐式完成与物理 BASE-DATA-TYPE A_UNICODE2STRING 之间的转换。 可用的数据类型： Internal Physical A_INT32 A_INT32 A_UINT32 A_UINT32 A_FLOAT32 A_FLOAT32 A_FLOAT64 A_FLOAT64 A_BYTEFIELD A_BYTEFIELD A_ASCIISTRING A_ASCIISTRING A_UTF8STRING A_UTF8STRING A_UNICODE2STRING A_UNICODE2STRING 2.Linear 线性函数，通俗点就是个一元一次方程。将输入值与一个因子相乘并加上偏移量。(可选)得出的总和可以除以一个无符号整数常量。 $$ f(x) = \frac {V_{N0} + V_{N1} * x} {V_{D0}} $$ 需要精确定义一个 <COMPU-SCALE>。它包含 <COMPU-RATIONAL-COEFFS>，其中声明了<COMPU-NUMERATOR>和 <COMPU-DENOMINATOR>。分母应包含两个值。第一个是偏移量$V_{N0}$，第二个是系数$V_{N1}$。如果存在分母，则应精确指定一个无符号整数值。可以使用 <COMPU-SCALE>的 LIMIT 来限制值域。 ...
1.收到运维同事消息，某台服务器磁盘io过高 2.使用pidstat 工具查询磁盘IO情况 # -p 指定进程号 # 4883 即进程号 紧跟 -p后面 # -t 展示进程下的线程资源占用情况 # -d 展示进程下的线程IO占用情况 # 1 每秒刷新1次 # 3 共刷新三次 [root]# pidstat -p 23218 -t -d 1 3 查询到是TID24151的线程数据异常（此处截图未包含异常线程信息） 3.使用jstack工具打印堆栈信息 # 4833 进程号 # > jstack.text 将堆栈信息打到 jstack.text 文件中 [root]# jstack 23218 > jstack.text 4.根据线程ID(24151)，在jstack.text中查询对应的堆栈信息 注意 此处根据 pidstat获取的线程号是 十进制。但是 jstack打印的堆栈信息中的nid是 十六进制，因此需要做一层进制转换，24151转十六进制为5e57 判断是xxl-job TriggerCallbackThread 线程异常 "Thread-57" #151 daemon prio=5 os_prio=0 cpu=4531531.18ms elapsed=87881.21s tid=0x00007f79edd9f160 nid=0x5e57 waiting on condition [0x00007f79609aa000] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep([email protected]/Native Method) at java.lang.Thread.sleep([email protected]/Thread.java:337) at java.util.concurrent.TimeUnit.sleep([email protected]/TimeUnit.java:446) at com.xxl.job.core.thread.TriggerCallbackThread$2.run(TriggerCallbackThread.java:121) at java.lang.Thread.run([email protected]/Thread.java:833 5.追踪xxl-job源码排查问题 ...
记一次MySQL字符串类型末尾包含空格导致的问题 起因： 测试同事反映自动化测试数据没有展示出来 排查发现是python统计脚本插入数据时，有唯一键索引错误 sqlalchemy.exc.IntegrityError: (pymysql.err.IntegrityError) (1062, "Duplicate entry 'xxx' for key 'xxx_key'") 而这些数据是从ClickHouse中GroupBy之后，写入MySQL。 ClickHouse中数据： id new_version old_version 1 v1 ‘v2’ 2 v1 ‘v2 ’ (尾部有一个空格) 执行的SQL SELECT new_version, old_version FROM tablexxx GROUP BY new_version, old_version; clickhouse中的结果 new_version old_version v1 v2 v1 v2 由于是在腾讯云的控制台上执行的SQL，所以结果中显示的‘v2’都是一样的，感到十分不解。后面转了Base64后才发现有所不同。 既然不相同，为什么插入MySQL还会报错呢？ 在MySQL中制造模拟数据执行上述SQL后发现如下结果： MySQL中的结果 new_version old_version v1 v2 MySQL中的结果只有一条！！！ 在stackoverflow上找到了一个类似的问题，先上地址：url 结论： 根据 MySQL 的默认设置，对于字符串类型的列，尾部的空格会被忽略，因此 ‘v2 ’ 和 ‘v2’ 在比较时被认为是相等的。 MySQL官方手册里的说明 大意就是MySQL校对规则有一个pad属性，默认采用“PAD SPACE”。只有某些基于UCA9.0.0或之上的Unicode校对规则是“NO PAD”。 ...