Javascript是一门事件驱动，非阻塞式I/O模型的语言。虽然在一般的实现上，它是单线程的，但是由于它本身的一些设计机制，导致了它实际上是一门在面向高并发场景下执行效率非常高的语言。
在js中，一旦有事件产生(例如：网络连接建立，网络数据包到达，磁盘I/O操作完成，定时器到时触发)，js就会将其加入到事件队列里，再进行处理。实际上，js在执行的时候，其主要的流程可以看做是一个叫Event Loop的东西

while(true)
{
    if(EventQueueIsNotEmpty)
    {
        Pop the front item of the event queue.
        Execute it.
    }
}

可以从这段伪代码可以看出，只要某个事件的处理代码开始执行了，除非它本身出让它的执行权，对于js运行环境来说，所有的cpu时间都由它独占，其他的事件必须等待它处理完成才会开始处理。

这里举一个例子

console.log(1)
let i = 0
setTimeout(function(){
	console.log(2)
},1000)
console.log(3)
while(true)	i++
console.log(4)

代码中设定了一个定时器，规定在1000ms后输出2。在执行过程中，控制台里只会出现1 3，2永远都不会出现。因为当前执行的事件一直处于执行状态。虽然在1000ms后定时器触发，往控制台输出2的事件加到了事件队列里，但将永远都没有开始执行的机会。

0x01 为什么需要异步

在计算机中，相对CPU的执行速度而言，I/O操作(如磁盘读写、网络传输、键盘输入等)是非常非常慢的。这里以磁盘读写为例，要从机械硬盘上读数据，至少需要大概10ms的时间，而在这10ms的时间内，cpu已经可以执行10^7次加法运算了。所以，如果在执行I/O操作时，让cpu一直处于等待状态，无疑是低效的。那么，这个问题如何解决呢？首先明确我们的目的，要在I/O操作完成前不要白白浪费CPU。其中一种解决方法是使用多线程。例如我们编写了一个简单的HTTP服务器，负责将磁盘上的文件发送给请求的用户。那么我们就可以对于每个用户的请求启用一个新的线程来处理，这样就可以大大增加了软件的吞吐量。但是，如果使用多线程的话，就要另外花费精力去处理一些附加的问题，如锁的问题。
假如每个线程都执行下面这一个操作，其中i是一个全局访问的变量，初始为0

int a = i;
a = a+1;
i = a;

假如我们执行了100个这样的线程，在所有线程执行完后，i的结果往往不是100。因为在多线程的执行的时候，由于实际cpu数量并没有这么多，并不是真正意义上的并发执行，是每个线程执行一段时间，暂停，再让另一个线程执行一段时间，这个过程一般是由操作系统来控制的。所以很有可能在执行完a=a+1时，这个线程就立刻被暂停了，而在其它线程里面i的值被更新，当这个线程恢复执行的时候，它就将旧的a更新到i上。最终100个线程执行完后得到的并不是我们本意要的结果。
那么，要如何解决了？我们可以通过加锁来处理，来保证同时只有一个线程会执行这三行代码，当有线程在执行这三行代码时，其他线程不得进入这个代码区域，来确保对i的值的更新是原子的。
显然，在多线程下，因为有很多事情是无法预知的，这就需要程序员花费额外的精力去处理一些棘手的事情，同时也容易因为考虑不周全产生其他bug。
而javascript的事件驱动模型，就很好的解决了上面这些问题。首先，在js的代码中，并没有并发执行这种概念，意味着同一时间内只会有一段代码执行，并且在执行的过程中不会被其他的事情打断，这样就从执行机制上很好的避免了多线程中需要保证原子操作的要求。同时，对于I/O操作，可以将其交由外部组件处理，要求在I/O操作完成时触发一个事件。这样，代码在执行的过程中，如果遇到I/O操作，就可以将I/O操作完成后要执行的代码封装好，然后将I/O交给外部组件处理，之后即可交出代码的执行权，让执行器执行下一个事件，等到I/O操作完成后再“唤醒”自己，将未完成的操作完成。这样，就能让CPU一直处于工作状态，不会因为等待I/O而空转。
下面，将用一段常用的代码来辅助说明一下

var xhr = new XMLHttpRequest()
xhr.onreadystatechange = function() {
    if(xhr.readyState==4 && xhr.status==200){
        console.log(xhr.responseText)
    }
}
xhr.open("GET","test.txt",true)
xhr.send()
console.log(1)

在执行xhr.send()之后，就会将该http请求交由外部组件处理，同时该函数将会立即返回，执行下面的console.log(1)。注意此时http请求尚未完成。待到该http请求完成时，将会在事件队列中加入这一事件。在事件队列中轮到该事件时将会执行预先定义好的处理代码：

if(xhr.readyState==4 && xhr.status==200){
        console.log(xhr.responseText)
    }

很多初学者会认为在xhr.send()执行完后意味着http请求已经完成，这是一种错误的想法。
也有人可能会想，那我能不能在xhr.send()下通过死循环来检测请求是否完成呢？

while(xhr.readyState!=4) continue;
console.log(xhr.responseText)

然而，很遗憾，代码将永远都不会跳出那个循环。回想下前面提到的Event loop，在http请求完成时，将会将事件放到事件队列等待执行。而这段代码一直在执行，没有机会给请求完成后进行处理，从而xhr.readyState永远都不会得到修改。

0x02 Promise

在ES6还未定制之前，对于这种需要异步操作的场景，都需要用到回调函数(callback)这种东西，即指定任务完成时该进行什么行为。如上面的

xhr.onreadystatechange = function() {
    if(xhr.readyState==4 && xhr.status==200){
        console.log(xhr.responseText)
    }
}

但是，设想一下，如果我们要依次发出多个请求，并且要求每个请求都要在上一个请求完成后再发送，那么就只能再回调函数里面再创建一个请求，再在他的回调函数里面再创建一个请求....这样写下去，可想而知，你的代码的最后面是长这样的：

        })
       })
      })
     })
    })
   })
  })
 })
})

这样的代码很丑就不说了，关键是非常难以维护。假如要往这一堆代码中加另外一个http请求，就必须要小心翼翼地去修改。这就是常说的回调地狱。
在ES6中，有一种好用的东西叫Promise，通过它就能很优雅的处理要用到异步操作的代码了。
相比而言，Promise更像是一个包装器，它可以将异步操作的代码包装起来，使其调用起来更加优雅，同时使以往使用回调函数难以实现的操作以一种十分简便的方法就能得以实现。
正如Promise字面意思说讲，Promise是一种承诺，承诺交给它的东西一定会完成，无论是成功还是失败。一个Promise对象有三种状态，分别是pending，fulfilled，rejected，分别对应事件正在/还未执行，事件执行完成，事件执行过程抛出了错误。一旦状态发生了改变就意味着状态将不会再发生改变。
在ES6中，Promise对象是一个构造函数，用来生成Promise实例，它接受一个函数，并将会往其传递俩函数，以让函数内部改变该Promise实例的状态。
首先，我们从创建一个Promise实例说起。

let promise = new Promise((resolve, reject) => {
    console.log(1)
    let xhr = new XMLHttpRequest()
    xhr.onreadystatechange = function() {
        if(xhr.readyState==4){
            if(xhr.status==200)
                resolve(xhr.responseText)
            else
                reject(new Error(xhr.statusText))
        }
    }
    xhr.open("GET","test.txt",true)
    xhr.send()
})
console.log(2)
promise.then(response => {
    console.log(response)
}).catch(error => {
    console.log(error)
})

在上面的代码中，创建Promise实例时提供的函数会立即执行，而在对于这个函数，Promise提供了俩个参数，分别是resolve与reject，用于给内部代码改变当前Promise实例的状态。
如果代码正常执行，只需调用传进来的resolve函数。如果有需要传出去的内容，作为resolve函数的参数即可，如上文代码中response即为传出去的xhr.responseText。
而如果发生了错误，就该调用reject。
PS:在调用完resolve与reject之后，该promise的实例的状态并不会立即改变，而是会将其放入事件队列中，轮到该事件时状态才会改变。
在创建完promise实例后，如上文所述的行为一样，http请求尚未完成。接下来我们就该指定该异步事件完成后该执行的代码(即上文的回调函数)
Promise提供两个api用于处理结果，then与catch，分别用于处理fulfilled状态与rejected状态的。在指定了处理函数后，同样的，在promise状态发生改变后会将其放入到事件队列中，轮到其时再执行相应的代码。
另外一点需要提到的是，Promise支持链式调用。调用then与catch后会返回一个Promise实例。但注意then和catch的行为是不同的
对于then而言，传递到参数里面的是上一个then里面所return的东西。如果它是一个Promise实例，那么下一个then会在该Promise变为fulfilled状态后执行，而函数里面的得到的就相对应的变成了resolve里面的参数。利用这一个特性我们可以以另一种更加优雅的方式去处理上文提到的那个问题。

function getUrl(url){
    let promise = new Promise((resolve, reject) => {
    let xhr = new XMLHttpRequest()
    xhr.onreadystatechange = function() {
        if(xhr.readyState==4){
            if(xhr.status==200)
                resolve(xhr.responseText)
            else
                reject(new Error(xhr.statusText))
        }
    }
    xhr.open("GET",url,true)
    xhr.send()
    })
    return promise
}
getUrl(first_url).then(e => {
    console.log(e)
    return getUrl(second_url)
}).then(e => {
    console.log(e)
    return getUrl(third_url)
}).then(e => {
    console.log(e)
    console.log("finish")
}).catch(error => {
    console.log(error)
})

对于catch而言，它的行为与then不同。当某个地方的promise的状态改为rejected时，将会从那个promise实例开始往链后面找，直到找到第一个catch，再将其作为rejected的处理函数。如上面的代码，前三个promise如果出现了rejected，将立即停止后面的then的执行，并交给其后第一个catch进行处理。

此外，Promise还提供了两个非常有用的静态方法，分别是Promise.all() 与Promise.race()
他们都接受一个包含promise实例的数组作为参数，并在调用后返回一个promise实例。而他们的行为有所不同，Promise.all()仅在传给他的所有的promise实例状态都改为fullfilled才会将状态改为fullfilled，而Promise.race()只要有一个promise实例状态改为fullfilled就会变为fullfilled。
例如如果我们要拉取100个url，就可以创建100个promise，达到了100并发请求的效果，然后通过Promise.all()就可以方便的等待他们都执行完后统一进行处理。

0x03 async/await

这是ES2017才引入的新的语法糖，他让异步操作变得更为方便，使得异步操作写起来就像同步代码一样，同时又保留其本身的特性。
使用起来也非常简单。对于一个函数，如果在其声明前添加async标识，就意味着这个函数内部含有异步操作，并且执行器将会对其进行一定的改造：
1、允许其内部使用await
2、对于其return的东西，将会自动对其包装成一个Promise实例，当然对于return的东西的类型不同会有不同的行为，例如如果是非promise实例就直接封装，如果是promise实例或者是有then方法的对象，就将其变为等价的promise返回，与上文链式调用中提到的一致。说白了，实际上是将return的东西加一层Promise.resolve(value_to_return)，具体可看这个api的作用，便于理解。
3、对于函数内部抛出的未捕获的异常或者await后面的promise对象状态变为rejected状态且其链上没有catch函数，该函数将会终止运行，并且其返回的promise对象的状态将会改为rejected。

await

await这个语法糖也很有趣。await后面跟的是一个promise实例（或者说，同上文一样，非promise实例会调用Promise.resolve()）。实际上await的作用是"等待"其后的promise实例状态改变为fullfilled，再将其内部的resolve里面的参数提取出来，并作为整体的一个返回值。
下面举一个例子：

function getUrlPromise(url){
    let promise = new Promise((resolve, reject) => {
    let xhr = new XMLHttpRequest()
    xhr.onreadystatechange = function() {
        if(xhr.readyState==4){
            if(xhr.status==200)
                resolve(xhr.responseText)
            else
                reject(new Error(xhr.statusText))
        }
    }
    xhr.open("GET",url,true)
    xhr.send()
    })
    return promise
}
async function getUrlsConcurrent(urls) {
	let promises = urls.map(e => {
		return getUrlPromise(e)
	}
	return Promise.all(promises)
}
async function getUrlsOneByOne(urls){
	let contents = []
	for(let i = 0;i < urls.length; i++)
	{
		contents.push(await getUrlPromise(urls[i])
	}
	return contents;

}
(async () => {
	let contents = await getUrlsConcurrent(["https://www.baidu.com/", "https://google.com/"])
	console.log(contents)

})()

在这个例子中，我们定义了三个函数，其中getUrlPromise并没有使用async，而是返回了一个promise实例，而getUrlsConcurrent和getUrlsOneByOne是async函数，内部使用了await，但是其后跟的是返回promise的一个函数。如getUrlsOneByOne中，每个await的地方都会等待后面的promise执行完成后才会继续执行下去，对于程序员而言这段代码是阻塞式运行的，但实际上他还是异步执行的。多亏了这些语法糖使得代码更为直观。这个函数的行为正如名字所言，将一系列请求依次执行。
而对于getUrlsConcurrent，函数中先是生成了所有的promise实例（这里并没有await所以并不会"阻塞"），再来个Promise.all()，行为就是一次性发出所有请求。
再在最后一个函数里(由于不能直接使用await所以套了一层闭包)，这个await是对一个async函数使用的，实际上和await对promise实例使用时一样的。
在具体执行机制中，对于async函数，在执行时还是会立即执行，但是一旦遇到await操作就会将之后的代码封装成一个事件，扔进事件队列里，等待事件完成时"唤醒"继续执行。当然实际处理可能不是这样，但可以直接这样理解。

总结

由此可以看出，随着语言的发展，一些以前实现起来不方便的东西现在就变得非常方便了。这个异步问题的解决是一步一步慢慢来的，从一开始的回调事件再到promise再到async/await（其实在这之前还有一个generator函数，本人认为直接将async/await理解为对promise的封装更易于理解，所以这里就省略了。具体可看阮一峰老师的es6入门教程）。而于此同时javascript由于语言本身的特性导致他在I/O密集型的应用中(如web服务器)会有极高的效率，所以其在后端领域也有了一席之地(nodejs)。可以说，ES6是js语言的一个分水岭，在此之后js是一门非常强大的编程语言。
还有一个问题，就是js是单线程执行的，可能会导致无法在多核机器上发挥全部的性能。实际上这个问题正在被解决(或者说已经)，在浏览器端有web worker，可以充分利用多核资源，在后端有node的cluster，都对这个问题有了一定的解决。

参考资料

JavaScript 运行机制详解：再谈Event Loop http://www.ruanyifeng.com/blog/2014/10/event-loop.html
Concurrency model and Event Loop - MDN https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop
ECMAScript 6 入门 http://es6.ruanyifeng.com/
art of node https://github.com/maxogden/art-of-node

最近入了一台独立服务器，如果直接拿来跑项目的话就太浪费资源了。于是打算使用Proxmox VE这款虚拟化管理软件进行VPS管理。

Proxmox VE是一款套开源的虚拟化管理软件，用户可通过网页的方式来管理服务器上使用 kvm 以及 lxc 技术运行的虚拟机。同时提供了一些先进功能的支持，如集群、HA等。

0x00 安装

Proxmox VE是基于Debian进行开发的，主要有两种安装方式。
其一是通过官方提供的iso作为一个全新的系统安装
另一种方式是在已有的Debian系统上安装
手动安装时请务必保证网卡配置正确，若出错的话在不带IPMI的机子上很难处理。

安装完成后即可通过https://ip:8006/访问管理页面

另外，这里记录一下版本升级的方法。由于Proxmox VE是一家商业公司在运营，所以一些功能是需要购买订阅才能使用的，例如说版本更新功能。但是可以通过一些方法绕过限制。注意这些更新方法请勿用于生产环境中。

将软件源更改为测试源

修改/etc/apt/sources.list.d/pve-install-repo.list, 将 pve-no-subscription 修改为pvetest
然后apt三连即可更新为新版本。

apt-get update
apt-get upgrade
apt-get dist-upgrade

0x01 相关设定

对于kvm虚拟化的虚拟机，若想上传需要用到的iso文件，可以直接通过网页端上传，也可以直接将文件放入/var/lib/vz/template/iso/中
如果想对kvm虚拟机的启动参数进行调整，官方提供了api:qm set，具体可参照官方文档
对于lxc虚拟化的虚拟机，可以直接从系统中下载对应发行版的模板，无需自行下载。
可以直接使用LXC自带的api对lxc虚拟机进行管理，注意-n为虚拟机的id。

0x02 网络配置

对于多ip的服务器，本身官方就是按照桥接的方式做好网络配置的，直接在虚拟机中填写分配的ip即可。
对于单ip服务器，可以采用NAT的方法让虚拟机连上外部网络。这里介绍俩种方式。

采用QEMU自带的NAT

对于KVM虚拟机，可以直接在创建虚拟机的时候勾上NAT，这时候就会自动为虚拟机分配一个虚拟的子网并且虚拟机可以通过nat连接到外部网络，基本上是开箱即用。同时也支持端口映射，具体可参考官方wiki下的QEMU port redirection。但之前在使用的过程中，发现这个端口映射并不是很稳定。同时虽然这种方法很简单，但是虚拟机之间是隔离的，无法互通数据，这样就非常不灵活。
同时，LXC虚拟机是没有这种开箱即用的NAT的。

配置iptables创建子网以实现nat

主要思路是创建一个虚拟桥接设备并创建一个子网，然后将所有虚拟机包括宿主机都连接到这个子网内，再开启iptables的NAT功能。
编辑配置文件/etc/interfaces，以下是参考配置

auto vmbr2
iface vmbr2 inet static
    address 10.0.0.254
    netmask 255.255.255.0
    bridge_ports none
    bridge_stp off
    bridge_fd 0
    post-up echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up iptables -t nat -A POSTROUTING -s '10.0.0.0/24' -o vmbr0 -j MASQUERADE
    post-down iptables -t nat -D POSTROUTING -s '10.0.0.0/24' -o vmbr0 -j MASQUERADE

以上配置创建了vmbr2并且分配了一个子网10.0.0.0/24，同时宿主机(同时亦为网关)在这个子网内的ip为10.0.0.254。然后开启了内核的转发功能与iptables的NAT功能(其中vmbr0为通向外部网络的设备)。
若想添加端口转发直接在iptables中增加相关条目即可。
例如想要将宿主机vmbr0的80端口的tcp连接转发到10.0.0.102的80端口上：
iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 80 -j DNAT --to 10.0.0.102:80
如果想保存转发规则，使之重启后依然有效，则需要在/etc/interfaces相应位置加入

post-up iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 80 -j DNAT --to 10.0.0.102:80
post-down iptables -t nat -D PREROUTING -i vmbr0 -p tcp --dport 80 -j DNAT --to 10.0.0.102:80

通过以上方法就能组建一个灵活的子网了，kvm虚拟机和lxc虚拟机都可接入，并且都可以有端口转发。由于没有DHCP服务器所以要自行分配ip。注意创建虚拟机的时候将其挂载到vmbr2端口下。
我的服务器只有一个ip，所以内部组网就只能采取这种这种的方法了hhhh。为了充分利用资源，我将80，443端口转发到内部一台虚拟机上，这台虚拟机再使用nginx反代到内网的其它虚拟机，以充分利用单个ip。

启用BBR优化网络

目前的Proxmox VE版本的linux内核版本比较新，已经包含了bbr模块了。

修改sysctl.conf

echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf

保存生效

sysctl -p

检测是否已启用bbr模块

lsmod | grep bbr

如果含有bbr即说明内核内已启用bbr模块

事出

前几天部门上线了个新页面，结果刚上线不到一小时就出现了一点小锅，需要临时改代码。本来代码快要改完了，突然群里面传来了一句话

救火

当时心里面就凉了一大半。删数据就算了。。偏偏删的还是最重要的那个表。而这个活动今年刚增加了二维码分享功能，还没上线一小时就记录了341封信件，用户量正在指数级增加，停服是不可能停服的了（错误想法），顿时整个人就懵了。

尝试使用万能的bin log

在mysql中，有一种叫bin log 的东西，它是用于记录对数据库数据进行更新操作的所有SQL语句，同时还会在每条语句上附加上timestamp。理论上如果保留了数据库建立以来所有的bin log，无论进行了什么操作都能将数据恢复回来，可以说是删库后的一根救命稻草了。
由于之前有过数据恢复的经验，意识恢复的时候立刻登上服务器查看mysql的配置文件，然而

还有一点热量的心瞬间凉透了。

疾病乱投医

之后我们几个部长疯狂的在网上搜索资料，祈祷仍然有救（错误想法，当时就该立刻停掉mysql并导出所有数据）
经过一段时间的搜索，在前人删库的经验上得到了以下的指南

如果 数据库引擎是MyISAM 
    则 收拾东西跑路
如果 数据库引擎是Innodb
    则 还能抢救一下

赶紧看一下数据库配置，发现正好用的是Innodb引擎，似乎燃起了一点点希望。
同时，在看到这篇文章的介绍中强调了要立即关闭mysql导出数据时，才想起早该这样做，于是赶紧将该数据库下的所有文件都拷贝到另一文件夹中并拖到本地进行操作。

事情并没有那么顺利

回答的作者正是某数据库恢复工具的作者，于是我们找到了他开源的工具

undrop-for-innodb
并根据指引进行了一番尝试。

该工具要求被删库的数据库文件夹下的libdata1 文件

看了下介绍大概说的是从libdata中读出被删表的表结构，并据此推断出实际存储到数据库中的数据格式，然后将整个服务器硬盘dump出来后，通过raw的方式读取并匹配这样的数据结构模式，以达到数据恢复的目的。

这种方式还是非常巧妙地，但是对于我们而言代价很高，整个服务器的硬盘有1t，将其dump下来需要很长时间。并且我在使用该工具的过程中，发现貌似并没有读取出原表的索引，所以也只能暂时将其放入备选方案中。

BTW：这个工具直接编译会有编译错误，具体参照issue里面的这个回复修改代码即可

黎明前的曙光

时间已经到了半夜2点，然而依然没有什么头绪。我翻了下拖下来的文件，发现有俩个文件貌似有点意思
它们分别为ib_logfile0 和 ib_logfile1
看到log之后仿佛就有了希望，于是搜索了一番，发现这俩个文件是这个作用的：
Innodb是基于事务的数据库引擎，为了防止执行事务中途数据库崩溃导致数据不一致，它会在每次执行命令前将事务log进这俩个文件中。
看到这里瞬间整个人精神了，这俩个文件各有48M，而我们才上线1小时，望着里面写的日记应该还不算多，或许能从里面还原出所有的数据？

冥冥之中佛祖保佑

赶紧拿来一条已知数据中数据类型是int的数据在文件内搜索，果然找到了整个int，然而前后都是乱码。将编码调整为UTF-8后(notepad++是个好东西)出现了大量的中文！说明数据是还能抢救回来的。

但是日记文件中并没有任何规律。搜索一番之后也并没有找到任何关于整个文件结构的说明。有人曾经在mysql支持论坛中提问过这个问题，但是并没有得到有效的答复。想想也是，这个只是一个类似于临时文件的东西，再且其他人删库的话一定是删了上线很久的数据库了，这俩个文件中的数据早已被覆盖，拿来也没用。所以估计要想弄明白的话要去翻mysql的源代码。

然而，冥冥之中上github搜索了一波，发现了一个好像是学生的人写的课程作业，就是用来尝试解析ib_logfile中的增删改语句
https://github.com/KasperFridolin/mysql_forensics

但是在使用过程中，发现久久没有得到输出，并且内存一直在增长，不知道是不是脚本出现了什么bug，也只好暂时搁置。

走向胜利

于是乎，决定手写脚本导出数据。在比对每一条数据后发现，刚好有一个字段存的要么是半年要么是一年。于是决定全文搜索这俩个关键字，然后根据特征将每条数据分离出来。

继续观察后发现，刚好这个固定字段的前一个字段的长度是固定的，然后每条记录后面都会出现表的名字的字样，并且在数据的末尾会有一个二进制标记符表示记录的结束。说干就干，拿起PHP就写代码（没错我就是喜欢用PHP写CLI脚本23333）
于是有了这下面的一段代码

<?php
$all_data = file_get_contents("ib_logfile1_other.txt");
$in = fopen("ib_logfile1_other.txt","r");
$out = fopen("out.txt", "rw");
$pos = 0;
$data = "";
$count = [];
function find0x99($data,$start){
  $len = strlen($data);
  while($start < $len)
  {
    if($data[$start] == chr(153))
    {
      return $start;
    }
      
    $start++;
  }
  
  return false;
}
function backfind0x99($data,$start){
  while($start > 0)
  {
    if($data[$start] == chr(153))
    {
      return $start;
    }
      
    $start--;
  }
  
  return false;
}
while($pos < strlen($all_data)) {
  $tmp = strpos($all_data, "一年", $pos);
  if($tmp ==false)  break;
  $tmp = $tmp - 10;
  $tmp2 = strpos($all_data,'qrcode_msg',$tmp);
  $tmp3=strpos($all_data,"online_msg",$tmp);
  if($tmp3>0 && $tmp3<$tmp2)
  {
    $pos = $tmp3;
    continue;
  }
  
  if($tmp2 ==false) break;
  $tmp2 = backfind0x99($all_data,$tmp2);
  if($tmp2 ==false) break;
  $target = substr($all_data,$tmp,$tmp2-$tmp);
  $target = str_replace(" 一年","一年 ",$target);
  $id = substr($target,0,8);
  $file = fopen("out/$id.txt", "a");
  fwrite($file, $target ."\n\n\n\n");
  fclose($file);
  $data =$data . $target . "\n\n\n\n";
  $pos = $tmp2 + 1;
}
$pos = 0;
while($pos < strlen($all_data)) {
  $tmp = strpos($all_data, "半年", $pos);
  if($tmp ==false)  break;
  $tmp = $tmp - 10;
  $tmp2 = strpos($all_data,'qrcode_msg',$tmp);
  $tmp3=strpos($all_data,"online_msg",$tmp);
  if($tmp3>0 && $tmp3<$tmp2)
  {
    $pos = $tmp3;
    continue;
  }
  if($tmp2 ==false) break;
  $tmp2 = backfind0x99($all_data,$tmp2);
  if($tmp2 ==false) break;
  $target = substr($all_data,$tmp,$tmp2-$tmp);
  $target = str_replace(" 半年","半年 ",$target);
  $id = substr($target,0,8);
  $file = fopen("out/$id.txt", "a");
  fwrite($file, $target ."\n\n\n\n");
  fclose($file);
  $data =$data . $target . "\n\n\n\n";
  $pos = $tmp2;
}
file_put_contents("out.txt", $data);

最后，成功将所有数据挽救了回来

总结

首先，最重要的一点是，在线上数据库上执行SQL语句一定要谨慎再谨慎。

这次某人删库是因为精神状态不好，本来只是想select一下，于是翻mysql的执行记录，找到一条差不多的语句就无意识地按下了enter。而实际上，执行的语句恰好是上线前清空数据表的语句。有个定律好像是说墨菲定律，如果你觉得某件不可能的事情可能发生，那他很大概率会发生。谁会想到竟然会出了删库这种事情，而且起因又这么戏剧化

其次，保存好bin log+定期异地备份。凡事都留一手冗余，因为谁也不知道会发生什么。

再者，如果真的出事故了第一件事要做的事是保留现场，立即关掉mysql+关闭服务器，以防被删除的数据被覆盖了，以便留下哪怕是那么一点点希望。而这次我们得以恢复数据，完全靠的是运气，正好是刚上线就出事故了，写入的数据量少还没被覆盖。

冥冥之中，佛祖保佑

博客吃灰好久了，翻了下之前写过的文章，发现好像都是黑历史，所以还是都删掉吧。

也忘了博客是什么时候建立的了，印象中换过俩次域名，在wordpress那边最早的文章是2012年2月，而目前使用的域名注册日期是2012年7月，这个博客也算是存活好久了。

近几年来学到了很多东西，但一直懒得把东西都记录下来。那就从现在开始好好写博文吧。