Sublime入门

目录

文档

参考资料

激活码

插件

常见问题

  1. 如何更改Markdown背景颜色?
    选择配置文件:Preferences -> Package Settings -> Markdown Editing
    更改用户配置,粘贴到json配置中即可
    "color_scheme": "Packages/MarkdownEditing/MarkdownEditor-Dark.tmTheme",

  2. 汉化版Package Control无法使用?
    建议升级最新版

  3. 每次要手动保存,太麻烦?
    请下载auto-save插件

postman入门

目录

文档

常见问题

  1. 沙箱中如何使用jquery? 如 $.each?
    说明:jQuery已经不被推荐,取而代之的是cheerio。
    使用方法:$.each => _.forEach
    官方说明
    文档

  2. postman 设置格式,每次都要手动转换成json?
    说明:postman 返回格式是auto,会自动识别,但是效果不好,会把json当初字符串来解析。
    解决办法:在设置更改格式为json

  3. postman可以用来做啥?
    不仅仅可以用来测试接口,还可以做接口自动化测试,生成api文档。

  4. runner里执行的时候,一定要注意request的是要保存里的,不然更改了是无效的。send本身是直接起效

  5. 如何传递数据?
    键名设置为key[]
    array[] => 1
    array[] => 2

  6. 返回的数据有问题,怎么处理?

try {
    data = JSON.parse(responseBody);
} catch (err) {
    tests["返回错误格式"] = true;
}

下单接口优化

背景

对于比较关键的下单接口,性能直接影响到商户的使用体验。目前,我们的下单接口大部分耗时都在4s-5s之间,少数耗时在2-3s。具体耗时多少,也和实际覆盖到的流程有关,不同分支流程,需要处理的业务逻辑往往不一样,调用接口数量也不一样。

思路

4s-5s耗时算比较多的,考虑到有些商户网络比较差,客户端从下单到接收到返回数据的实际耗时会更多,实际体验也会更差。

缩减耗时,可以从mysql优化入手,但是我们的sql已经挺快了(我的意思是,它的优化空间并不是很大,继续优化的难度会越来越大),网络耗时的优化也难以有很明显的效果。

从ztrace的监控面板上可以看到,几乎所有请求都是串联的,只要改为并发,就可以大大减小接口总耗时。这么多的接口,只要拿5、6个做并发,就可以节省接近1s的时间,所有优化空间很大。

特别是一些诸如“获取用户信息”、“获取商户信息”、“获取商品信息”之类的接口,它们对执行顺序没有特别要求,完全可以在接口开始时就做并发。

调用链跟踪系统的一个巨大优点就是直观,每个部分的耗时都可以显示出来,并且进行对比。

操刀

PHP有对并发访问的支持:curl_multi_init,但是要用到我们项目里,要尽量减小对原流程的干涉,所以做了一些独特的设计。

cURL批处理的用法,是先初始化一个批处理句柄:curl_multi_init,然后通过curl_multi_add_handle把普通的curl句柄加入批处理句柄,再统一执行(并发)。

下面是一个例子,来自:php.net

<?php
// 创建一对cURL资源
$ch1 = curl_init();
$ch2 = curl_init();

// 设置URL和相应的选项
curl_setopt($ch1, CURLOPT_URL, "http://www.example.com/");
curl_setopt($ch1, CURLOPT_HEADER, 0);
curl_setopt($ch2, CURLOPT_URL, "http://www.php.net/");
curl_setopt($ch2, CURLOPT_HEADER, 0);

// 创建批处理cURL句柄
$mh = curl_multi_init();

// 增加2个句柄
curl_multi_add_handle($mh,$ch1);
curl_multi_add_handle($mh,$ch2);

$running=null;
// 执行批处理句柄
do {
    usleep(10000);
    curl_multi_exec($mh,$running);
} while ($running > 0);

// 关闭全部句柄
curl_multi_remove_handle($mh, $ch1);
curl_multi_remove_handle($mh, $ch2);
curl_multi_close($mh);

?>

我直接找了一个相关库,并把它clone到了公司github上,保留了授权(感谢Apache License,感谢作者,附上原地址:jmathai/php-multi-curl,内部项目地址:shop/php-multi-curl

为了少改业务流程,我设计了一个方法:preExec,它的参数和execApi一样。
它的作用是生成请求的curl句柄,并将其加入到批处理(还没执行),然后计算请求的hash,设置$ci->preExec[$request_hash](可以通过它去获取这次请求的结果)。

如何计算请求hash:请求hash的计算元素,包括请求url、请求params、请求method。

function requestHash($url, $p, $method)
{
    $url = strtolower(trim(trim($url), '&?/\\'));
    $phash = $this->arrayHash($p);
    $method = strtolower(trim($method)) == 'post' ? 'post' : 'get';
    return md5($url . $phash . $method);
}
function arrayHash($p, $filter = array('mdstr', 'expire'))
{
    $para_sort = array();
    foreach ($p as $k => $v) {
        if ($filter && in_array($v, $filter, true)) continue;
        // array object bool int float null resource...
        $para_sort[$k] = is_array($v) ? $this->arrayHash($v)
            : (is_object($v) ? $this->arrayHash((array)$v) : strval($v));
    }
    ksort($para_sort);
    return md5(http_build_query($para_sort));
}

当我们去主动获取请求结果时,如果当前请求已经执行完成,会立即返回请求结果,其他还没执行完的请求继续执行,不堵塞业务流程。如果当前请求没执行完,会堵塞直到当前请求执行结束。

执行execApi时,先判断是否有设置$ci->preExec[$request_hash],如果没设置,就是一次普通的curl访问,和以前的流程一样(单次请求,堵塞直到获取到结果);如果有设置,那就执行curl批处理(所有的并发请求都在这时开始执行。如果已经执行过了就不再执行),并通过$ci->preExec[$request_hash]去获取当前请求的结果。获取到结果后,会将$ci->preExec[$request_hash]删除。

所以,只要我们在流程开始前执行preExec,那执行到execApi的时候就会自动做并发,并获取结果。

在流程1和流程2,execApi分别执行普通curl访问、并发curl访问。

DEBUG流程

下面讲一些遇到的坑。

开始做并发时很顺利,也成功实现了并发。但是当我把它和调用链跟踪结合起来的时候,一大堆问题就来了。

为了准确跟踪接口调用时间,我们需要记录每个curl的执行开始时刻,和执行过程的耗时。

每创建一个curl句柄后,我们都会向curl批处理会话中添加这个单独的curl句柄,但是这个时候curl是没开始执行的。如果我们把创建curl的时刻作为url开始访问的时刻,记录到的接口生命周期会比实际的长很多(提前记录了)。

这时我想到了通过记录curl结束时间和curl耗时,反推开始时间。而curl有个回调函数,可以在接收到数据的时候执行:CURLOPT_WRITEFUNCTION(有没有curl开始执行的回调函数呢?很遗憾没有!)

于是,我使用了CURLOPT_WRITEFUNCTION来记录curl调用的结束时刻。但是在235上,设置CURLOPT_WRITEFUNCTION后总是得不到返回数据(curl_exec总是返回TRUE),我发现CURLOPT_RETURNTRANSFER设置失效了!

** 235上的libcurl版本是:7.19.7**

CURLOPT_WRITEFUNCTION 回调函数名。该函数应接受两个参数。第一个是 cURL resource;第二个是要写入的数据字符串。数 据必须在函数中被保存。 函数必须准确返回写入数据的字节数,否则传输会被一个错误所中 断。

CURLOPT_RETURNTRANSFER TRUE 将curl_exec()获取的信息以字符串返回,而不是直接输出。

一顿折腾,在Stack Overflow上找到一点提示 ready go

When I placed that line before any of the other options, it was simply ignored.

我尝试在设置CURLOPT_WRITEFUNCTION后再次设置CURLOPT_RETURNTRANSFER,这次跑通了。

BUT!我自己的电脑上又出问题了,设置了CURLOPT_WRITEFUNCTIONCURLOPT_RETURNTRANSFER就失效,CURLOPT_RETURNTRANSFER生效的时候,就不执行CURLOPT_WRITEFUNCTION。在需要二选一的时候,我选择了放弃。

** 我电脑上的libcurl版本是:7.55.0**

我放弃了CURLOPT_WRITEFUNCTION。找到了一个替代回调函数CURLOPT_HEADERFUNCTION,这个函数会在接收到返回的header信息时调用。虽然它不能精确表示结束时间,但是马马虎虎也能用。最重要的是,这个函数始终都会被调用。

CURLOPT_HEADERFUNCTION 设置一个回调函数,这个函数有两个参数,第一个是cURL的资源句柄,第二个是输出的 header 数据。header数据的输出必须依赖这个函数,返回已写入的数据大小。

这时,调用链跟踪和并发成功结合起来了,监控的数据基本正确,也能正常运行。

如果看到ztrace上面,一个并发前只需要100ms+的接口,在并发后要800ms+,请相信我,curl_getinfo($ch, CURLINFO_TOTAL_TIME)返回的就是这个值,不是程序有bug。具体原因期待大神解释。

调试过程中还遇到一个libcurl的bug,这个bug只在 7.55.0 上有(没错,我电脑上的就是这个版本:broken_heart:)。这个bug就是curl_getinfo($ch, CURLINFO_TOTAL_TIME)会在某些时候返回一个超大的浮点数,比如4295.xx。而经过我观察,只需要减掉4295就行了(究竟对不对,就看我猜的对不对了:pray:)

结语

好了,上面是修改ApiShopClient的整个过程,主要时间花在了适配调用链跟踪上面,从这个debug流程也能看到,php在涉及到底层的时候有点力不从心(大神忽略掉这句)。

调用链跟踪系统-介绍

背景资料

Dapper,大规模分布式系统的跟踪系统

Zipkin

如果要查看zipkin资料,官网的英文文档是最正确的,讲解也很系统;

在阅读文章前,建议先至少看一下Dapper的翻译;

一、介绍

调用链跟踪系统进行了比较大的升级,主要改变有:

  1. 对接zipkin日志标准(仍保留了些许不同);
  2. 使用zipkin的数据库和界面;
  3. 大幅降低对正常业务流程的性能影响;
  4. 将数据压缩后再传递给收集器;
  5. rabbitmq使用单独的数据通道,不再和业务共用一个;
  6. 采用文件日志和mysql记录结合的方式,分别记录调用链的业务数据和性能数据。 业务数据100%记录,性能数据采样记录(5%);
  7. 支持业务数据的上下文透明传输

下面详细讲解系统的构成、设计考量、使用和特点。

二、结构

分布式跟踪系统整体结构

浅绿色的是数据最终落地的地方。

名词解释:临时存储

临时存储究竟是干嘛的呢?在zipkin里,一个Span被分割成两部分,一个是Client/Producer,另一个是Server/Consumer。Span的含义更接近于一次RPC,它横跨了两个服务节点,所以在两个节点分别上报信息,最后再合并成一个Span。

后端收到两部分Span的时间不一样,临时存储就用来存储先到达的Span,等另一半到达后再取出来做合并。

名词解释:收集器

从MQ接收上报的Span,做Span的合并,并存储到持久存储(mysql)

名词解释:压缩

压缩成二进制,再通过MQ传递。实际应用中,是先将Span转换为数组,将key替换成a-z的单字母,再转成json后使用zlib压缩(需要zlib扩展)。

和压缩相关的还有一个叫 msgpack 的东西,但是它需要单独安装PHP扩展,所以放弃了。

三、设计考量

考量一:降低对业务的影响

只在少数地方嵌入跟踪代码。实际操作中,在项目入口(index.php)、rpc请求、输出这三个地方做了埋点。

耗时操作在请求以外执行。我们知道PHP没有异步,但是PHP有个非常有用的函数register_shutdown_function,我们把耗时操作全放里面,这样可以尽量减少对线上业务的影响。如果是fastcgi模式,我们会优先使用fastcgi_finish_request这个函数。http://php.net/manual/zh/function.register-shutdown-function.php#108212

考量二:开关/采样率/消息生产速率控制

一共设计了两个开关(业务日志开关、Span上报开关),默认情况下这两个开关都是开启的。在此基础上,增加了采样率控制,仅当Span上报开关开启,且当前Span需要采样时,Span才会通过MQ传递给后端。业务日志开关控制biz-ztrace日志的记录。

需要注意的时,即便把开关全部关闭,traceid也会生成、传递,但不会有日志记录,也不会有Span上报。

对于消息速率控制,在实际中采用的是“过量丢弃”,阈值是10000。只要队列里的消息超过这个值,即不再接收消息,直接抛弃。

考量三:动态增加消费能力

随着系统扩大,采集的数据增多,动态增强数据的消费能力非常重要。目前的做法是通过加开消费者来实现。之所以能直接增加消费者,是因为它们使用的同一个临时存储,我们只是把消息的消费瓶颈,转移到了临时存储的IO瓶颈上。

想象一下,我们有两个消费者A、B,分别使用两个不同的临时存储,Client端的Span被A接收到,Server端的Span被B接收到,由于它们的临时存储隔开的,A、B都无法做Span的合并!

几乎所有的调用链跟踪系统实现方案,都绕不开这个问题,可能是一个Span被分发到不同处理实例,也可能是同一Trace的不同Span被分发到不同处理实例——这都会带来很多麻烦。

解决方法也很多,比如根据traceid做hash,再转发给不同的后端实例,这样同一个trace下的Span都会被,且只会被转发给同一处理实例。

但是,仅仅做hash是不够的,还必须借助“一致性Hash”算法。下面的例子解释了原因。

假设已经有一个处理实例CA,spanA、SpanB都属于同一个trace。CA已经接收到spanA了,这时我们新增了一个CB(和CA使用不同临时存储),如果hash结果表明spanB应该转发给CB(这完全可能发生),那又会出现CA、CB都无法合并这个Span的情况。

关于一致性Hash,我们后面再讲。

考量四:业务日志、性能日志分开

之所以要分开,是因为业务日志很多(随着采集端的增加,数据增长更多),我们还没处理过这么多的数据。

目前,业务日志记录了$_GET、$_POST、$_SERVER和apiReturn,收集端有seller和api。每天产生的日志共2.5G左右,每月日志总量大概在25G。日志总量和采集端数量呈正相关。

四、使用

下面的例子都有判断$trace_open;,并且使用了 try {} catch () {},这样做是为了减少可能出现的异常,必须要添加。

记录业务日志

业务日志是记录在文件里的,用的最多。

过期数据处理

我们把太久远的数据称为“过期数据”,因为它们被再次使用的概率很低。我们用的最多的是近期的数据,近期数据才是最重要的,业务日志和性能统计数据都适用这个道理。

我们处理过期数据的方式很简单——打包压缩、删除,这是目前能找到的最划算的处理方法。具体处理逻辑:

文件日志:保留一个月的压缩日志,保留一周内的原始日志。
数据库:保留两个月的数据。

global $trace_open;
if ($trace_open) {
    try {
        $tracer = \Tricolor\ZTracker\Core\GlobalTracer::tracer();
        $tracer->log('get', $_GET);
    } catch (\Exception $e) {}
}

记录跟踪日志

跟踪日志会出现在ui里(如果被采样了的话)

global $trace_open;
if ($trace_open) {
    try {
        $tracer = \Tricolor\ZTracker\Core\GlobalTracer::tracer();
        $tracer->currentSpan()->putTag('store_id', (int)$_POST['store_id']);
    } catch (\Exception $e) {}
}

透明传输业务字段(试验性质)

在调用链上游设置一个值,在调用链下游可以获取到。

之所以说是试验性质,是因为设计里有,也有实现,但实际业务里还没使用过。

global $trace_open;
if ($trace_open) {
    try {
        $tracer = \Tricolor\ZTracker\Core\GlobalTracer::tracer();
        $tracer->currentContext()->set('from', 'mamagou');
        // get
        $tracer->currentContext()->get('from');
    } catch (\Exception $e) {}
}

五、特点

  1. 和zipkin的Span比起来,我们的Span结构略有不同。zipkin里的Sampled字段,在我们这里对应Decision字段,Decision字段除了记录是否采样,还记录了log开关和report开关。

  2. 数据库、UI使用zipkin,减少了一些开发量。zipkin的Span设计能适应较多的采集场景,比如单向数据传递、黑盒模式的远端节点(调用数据库时,数据库就是一个黑盒模型)。

  3. 和淘宝类似,加了业务字段透传功能,业务日志和跟踪日志分开。

postman 实现API自动化测试

编 写:袁 亮
时 间:2017-01-16
说 明:postman 实现API自动化测试


一. 实现目的

  1. 接口开发调试工具
  2. 自动化测试
  3. 接口用例团队内共享
  4. 降低接口文档编写成本

二. 实现流程

  1. 团队使用同一份文档
    测试文档存入代码仓库
    使用前从代码仓库拉取导入
    修改完之后,重新导出,并更新代码仓库
    ps:后续为了降低代码层级,可以将API分成很多个collection,前期先合并成同一个

  2. 使用工具产生文档
    postman:界面gui模式
    newman:服务端cli模式

三. postman产生文档

  1. 通用层实现 在collection上做
    • 所有接口都先放在同一个collection,后期根据模块拆分
      方便在同一个collection上实现一些通用逻辑
    • 环境变量支持
      appid: 10101
      appsecret: 8e2160ec2b07f1faca9055be530bf09d
      host: http://api.shop.ci123.com/
      maxtime: 300
    • pre-request中实现签名
    • tests中实现统一的校验
      http状态码 200
      返回json,并且需要包含state和mess字段
      接口超时时间
      签名出错
  2. 目录层级规范
    • 根据模块不同,创建不同的文件夹
    • gui展示的原因,目录层级最多3层
    • 每一个接口,都是一个文件夹 (所以实质上除了collection只有2层目录)
    • 最底层的文件夹下,所有请求都是同一个接口的不同用例
  3. 具体实例实现
    • url地址
      {{host}}/Item/getSkuByItemId?appid={{appid}}
    • post参数增加两行
      expire {{expire}}
      mdstr {{mdstr}}
      ps:因为request只读的原因,不能追加,只能在每个地方都写一次这个
    • 填入其他请求参数,构造每一种apiReturn的情况
      一个用例只实现一个对应apiReturn,这个return可能有多种情况,放在examples里
    • 每个用例,必须增加tests,来告知是否通过
      除了最终成功的那个请求,其他请求的tests主要就是校验state状态码即可
    • 执行成功的用例校验
      写请求:一般是校验对应的id是否正确,比如订单id,商品id等
      读请求:解析对应的json数据格式,是否包含什么样的字段等等
      ps:后续谁有空可以看下,是否可以自己定义模板,现在看到的那些模板只能选择使用,不能自己创建
  4. 开发调试规范
    • 从代码仓库把文档导入到postman
    • 接口编写过程中,使用这个来进行调试,所有情况必须测到
      有多少个state返回,就最少有多少个接口用例
    • 接口全部写完之后,必须通过runner来确保所有用例全部跑通
      不要出现改到后面,前面的跑过的用例又跑不了
    • 写完之后,把postman里的数据导出到git仓库中

四、自动化测试 todo

  1. 安装newman环境
  2. 定时或者在git的钩子里设置
  3. 拉取对应的文档,执行测试
  4. 测试结果入库
  5. 展示报警
    工作台展示
    邮件、短信报警

五、postman常用操作

  1. 设置
    皮肤设置
    返回值解析设置:json auto的时候,没有自动识别是json
  2. 环境变量设置与使用
  3. 数据导入导出
    collection导入导出
    整体导入导出
  4. 复制修改
    用例复制,文件夹复制等
  5. examples使用
    可以配合做mock server
  6. runner使用
  7. console控制台调试
  8. 搜索
  9. API文档发布
    免费版有限制,可以大概看看
  10. 官方文档,可以快速看一遍
  11. 错误提示
    特别是全局变量中的
  12. runner里执行的时候,一定要注意request的是要保存里的,不然更改了是无效的
    send本身是直接起效
  13. ctrl + s保存修改
  14. Codeception

Elk 6.1 安装使用说明

ELK 不是一款软件,而是 Elasticsearch、Logstash 和 Kibana 三种软件产品的首字母缩写。这三者都是开源软件,通常配合使用,而且又先后归于 Elastic.co 公司名下,所以被简称为 ELK Stack。根据 Google Trend 的信息显示,ELK Stack 已经成为目前最流行的集中式日志解决方案。

架构

Logstash

介绍

数据收集引擎:数据存储与数据流。它支持动态的从各种数据源搜集数据,并对数据进行过滤、分析、丰富、统一格式等操作,然后存储到用户指定的位置;

安装

1、 官方教程
2、 windows下安装Logstash

效果图

注意事项

1、windows下需要使用NSSM

Elasticsearch

安装

说明:Elastic 需要 Java 8 环境,注意要保证环境变量JAVA_HOME正确设置。
1、下载最新Elasticsearch版本,解压到指定目录。
2、在Unix上运行bin/elasticsearch或者在Windows上运行bin\elasticsearch.bat
3、打开:http://localhost:9200/

效果图

注意事项:

  1. 启动内存不足
# vi ${elasticsearch_HOME}/config/jvm.options
#-Xms2g
#-Xmx2g
-Xms512m
-Xmx512m
  1. 无法以root权限启动
# groupadd es
# useradd es -g es -p es
# chown es:es ${elasticsearch_HOME}/
# sudo su es
# ./bin/elasticsearch

安装elasticsearch-head

git clone git://github.com/mobz/elasticsearch-head.git
cd elasticsearch-head
npm install
npm run start
open http://localhost:9100/

谷歌插件安装链接

说明

Kibana

介绍

Kibana是个数据分析和可视化平台。通常与 Elasticsearch 配合使用,对其中数据进行搜索、分析和以统计图表的方式展示;

安装

kibana官方文档

效果图

注意事项

1、 需要cmd执行,直接运行.bat无效
2、 Logstash 6.1.1 issue with setup.bat file "could not find jruby in"
在7.0版本修复,下载master文件,并替换bin目录文件接口。

参考资料
1. Kibana入门教程
2. Logstash 最佳实践
3. kibana官方文档
4. ELK+Filebeat 集中式日志解决方案详解

调用链跟踪系统的首秀—查找打印配置未正确加载的bug

背景

问题

连续两天都有商家反馈无法打印,远程查看后都发现打印配置加载的有问题,以前设置好的打印机都没显示出来——显示的是 store 级别的打印配置(打印配置从store细化到entity_store后,如果请求没有entity_store_id,会去查找store级别的打印配置)。

思路

调用链跟踪系统,记录了每次api请求的url、params、返回数据、时间戳、ua、x-forwarded-for、埋点标记 等有用信息,足够我们用来回溯当时的程序运行路径,展示当时程序的部分状态。

操作

  1. 首先从庞大的日志里筛选出需要的所有调用链;
    1.1 根据商家反馈,早上从未成功打印过,我们先确定了一个较小的时间范围:从商家第一次登陆,到打印配置获取完成;
    1.2 我们先在记录里找商家store_id第一次出现的位置,再根据这条记录的ua找到了商家ip,根据此ip筛选出第一批数据,也找到了大概的时间范围;
    1.3 把所有记录复制出来,分组排序(按TraceId分组,组内按RpcId排序,组间按每组内第一条记录的At排序),方便分析;
    1.4 根据TraceId和RpcId补足中间缺失的记录(RpcId是有序的,中间缺失可以看出来)
    1.5 最终筛选出来106条记录,时间跨度约5秒,其中seller端的cash/get/lists接口产生了11个Api调用,相关记录就占了46条);
  2. 找到“获取打印配置”这个接口的请求参数和返回值,发现接口传参不正确,获取到的数据也不正确;
  3. 结合记录和代码,推测程序运行路径,找出问题的原因。

效果

最后找出来一个bug:

check接口和返回值:


PS: 接口没返回entity_store_id,后面却使用了entity_store_id去获取打印配置。

结语

  1. 最终张跃还在js端找出一个bug:打印配置的获取 写在了 setCookie方法 前面,导致获取配置的时候没有取到ntity_store_id(所以也没传)。
  2. 打印配置的获取有三个地方:打印js加载后自动获取、doLogin时获取、checkLogin时获取,所以出bug后也只有部分商户无法打印。
  3. 调用链跟踪记录查阅起来还不是很方便,主要问题有:
    3.1 商家没有固定的身份标识,在记录里难以找出所有的商家相关记录;
    3.2 日志记录无序,还需要自己排一遍序;
    3.3 如果能像数据库一样select筛选数据更好;
  4. 针对上面的问题,分别有一些解决方法:
    4.1 在客户端里获取商家电脑的硬件信息,作为商家的身份标识;
    4.2 日志记录排好序再写到log里,可以保证组内绝对有序,组间相对有序;
    4.3 找一些开源工具。。

mysql 如何恢复数据?

问题:

尝试还原数据库,之后提示 table doesn`t exist。

分析:

类型:MyISAM
数据:Table.frm,Table.MYD,Table.MYI
位置:/data/$databasename/目录中
说明:直接复制到mysql中data目录中,便可以使用

类型:InnoDB
数据文件:存储在/$innodb_data_home_dir/中的ibdata1文件中
结构文件:结构文件存在于/data/table_name.frm中
说明:不可以直接使用,并报错:table doesn`t exist

解决方法:

1、 停止 apache 和 mysql服务
2、 拷贝相应文件到/data/目录,在数据库引擎类型为InnoDB时,拷贝数据文件的同时还需要拷贝ibdata1。
3、 将根目录下的ib_logfile*文件全部删除掉

备注:

1、 正常的数据导出恢复,最好用工具,不要在data文件层面去恢复
2、 测试环境在windows下

参考文档:

1、 mysql 直接从date 文件夹备份表,还原数据库之后提示 table doesn`t exist的原因和解决方法

在api里写可以平滑关闭的进程

背景

对于无关紧要的进程,我们可以随时kill掉再重启,但是有时候不能这样粗暴地操作。

假设我们正在处理一个从消息系统得到的消息,而消息是 非持久化/自动ack 的,如果进程被打断,这条消息就可能丢失。

或者我们在处理一个耗时特别长的任务,这时别人不小心kill掉了我们的进程,那我们前面的成果就付诸东流了。

针对上面这些情况,我们在Api进程里加入了平滑关闭的特性,你可以捕获进程关闭指令,自己决定何时关闭。

下面是一些使用方法:

使用

使用方法一:闭包

class Cront extends MY_Controller
{
    public function run()
    {
        $ready_exit = false;
        $this->regSig(SIGTERM, function() use (&$ready_exit) {
            $ready_exit = true;
            echo "准备退出!";
        });
        while (true) {
            {
                /**
                 * 括号里是业务处理代码
                 */
                echo "正在处理业务...\n";
                sleep(3);
                echo "业务处理完毕!\n";
            }
            $this->catchSig();
            if ($ready_exit) {
                echo "exit now!\n";
                exit;
            }
        }
    }
}

使用方法二:对象方法

class Cront extends MY_Controller
{
    public $ready_exit = false;
    public function handSig($sig, $my_var1, $my_var2)
    {
        switch ($my_var1) {
            case 'run':
                $this->ready_exit = true;
                echo "exit ready\n";
                break;
        }
        var_dump(func_get_args());
    }

    public function run()
    {
        $this->regSig(SIGTERM, array($this, 'handSig'), 'run', 'myvar');
        while (true) {
            {
                /**
                 * 括号里是业务处理代码
                 */
                echo "正在处理业务...\n";
                sleep(3);
                echo "业务处理完毕!\n";
            }
            $this->catchSig();
            if ($this->ready_exit) {
                echo "exit now!\n";
                exit;
            }
        }
    }
}

注意

  1. 进程捕获关闭指令后,用 kill -9 仍然可以杀死进程;
  2. api里的 regSig 不仅可以捕获 SIGTERM 信号,还可以捕获其他信号;
  3. 如果调用了 regSig 而没有调用 catchSig ,程序仍然捕获不到信号;
  4. 不用 declare(ticks = 1); 是考虑到性能;

npm私有包:键盘事件监听


编   写:袁 亮
时   间:2017-08-17
说   明:复杂页面交互,键盘快捷键监听组件

一、功能描述
    1、事件监听
        默认绑定keydown事件
        绑定单例,防止多次绑定,导致多次触发
            ps:vue如果代码自动刷新,会导致又绑定一次
    2、触发条件
        配置条件
            inInput:光标在输入框内是否触发
                true:触发,false:不触发,默认true
            needCtrl:是否需要同时按下ctrl键
                不传,不限制
                true:必须按下Ctrl
                false:不能按下Ctrl
            needShift:是否需要同时按下shift键
                同needCtrl
            needAlt:是否需要同时按下alt键
                同needCtrl
        自定义方法
            触发的时候,会执行该方法判断是否要执行,返回true或者false
            不传,默认true
    3、事件触发执行
        同一事件,多次绑定
            后绑定的优先级更高
        事件冒泡
            如果事件没有被响应,自动按绑定顺序冒泡
        事件互斥
            同一事件,只会触发一次,捕获后,不再冒泡
        默认行为阻止
            事件被捕获,默认行为将被阻止
    4、事件定义
        内置常见事件
            esc:取消
            backspace
            enter
            delete
            up
            down
            increase
            decrease
            
            number:数字
            float:浮点数
            letter:字母
        支持自定义事件配置
            优先级高于内置事件
        
二、使用方法
    1、安装包
        npm install @duomai/keylisten --save
        ps:先切换到多麦的源
    2、代码
        import KeyListen from '@duomai/keyListen'
        
        // 在created钩子里,使用内置事件,不需要setConfig
        KeyListen.setConfig(config.shortcutKey).add({
          up: function () {
            // todo up
          },
          down: function () {
            // todo down
          }
        })