1、简介传统的HDD具备大容量的优势，但是性能相对偏低，尤其是随机IO性能，经常成为系统的性能瓶颈，在虚拟机化环境下表现的更明显，因为虚拟化场景会加剧IO随机化。相比HDD，SSD具有高性能的优势，尤其在随机IO这方面，优势非常明显，但是SSD的硬件成本比较高。目前业界在结合HDD的大容量和SSD的高性能方面做了一些优化，基本思路是使用SSD作为HDD的cache，计算机领域，cache的思想无处不在，比如CPU的L1、L2 cache，raid card上的cache，TLB cache等。关于SSD作为HDD的cache的优化方案，主要有Linux bcache，Linux dm-cache，Facebook flashcache，btier，IBM flashcache等，本文主要介绍Facebook flashcache，它目前由Facebook维护，没有merge到kernel mainstream。2、原理介绍flashcache是建立在Linux devicemapper之上的，由devicemapper在SSD和backing HDD之上创建了一个逻辑的mapped device，用户使用的就是这个mapped device。flashcache把cache（SSD）按照哈希的方式进行结构化管理，如下图所示，每个方格代表一个block，默认大小是4KB，每个bloc ...继续阅读 (42)

1、简介传统的HDD具备大容量的优势，但是性能相对偏低，尤其是随机IO性能，经常成为系统的性能瓶颈，在虚拟机化环境下表现的更明显，因为虚拟化场景会加剧IO随机化。相比HDD，SSD具有高性能的优势，尤其在随机IO这方面，优势非常明显，但是SSD的硬件成本比较高。目前业界在结合HDD的大容量和SSD的高性能方面做了一些优化，基本思路是使用SSD作为HDD的cache，计算机领域，cache的思想无处不在，比如CPU的L1、L2 cache，raid card上的cache，TLB cache等。关于SSD作为HDD的cache的优化方案，主要有Linux bcache，Linux dm-cache，Facebook flashcache，btier，IBM flashcache等，本文主要介绍Facebook flashcache，它目前由Facebook维护，没有merge到kernel mainstream。2、原理介绍flashcache是建立在Linux devicemapper之上的，由devicemapper在SSD和backing HDD之上创建了一个逻辑的mapped device，用户使用的就是这个mapped device。flashcache把cache（SSD）按照哈希的方式进行结构化管理，如下图所示，每个方格代表一个block，默认大小是4KB，每个bloc ...继续阅读 (34)

1、问题现象有两台跑了docker容器的宿主机发生了自动重启，上面的容器都被迫关机了，影响了业务稳定。其中一台已经不止一次自动重启。2、相关信息我们的宿主机使用的CentOS。如何确定它发生过自动重启？使用 last reboot命令可以看到每次系统启动的时间，即可看到那些计划外的重启时间。1）无故重启，首先想到的是查看物理机的/var/log/messages日志。但是在重启时间点附近没有找到与重启相关的信息。2）在/var/crash目录下，保存了内核crash的日志vmcore-dmesg.txt ，内核crash时会保存crash信息到这个文件中。日志的生成时间与宿主机重启时间一致，可以说明宿主机是发生了kernel crash然后导致的自动重启。3、问题分析从vmcore-dmesg日志中可以看到crash的堆栈：<2>kernel BUG at drivers/md/persistent-data/dm-btree-remove.c:181! <4>invalid opcode: 0000 [#1] SMP <4>last sysfs file: /sys/devices/system/cpu/online <4>CPU 13 <4>Modules linked in: bonding ip6_tables ebtable_nat ebtables ipt_REJECT ...继续阅读 (38)

1、问题现象有两台跑了docker容器的宿主机发生了自动重启，上面的容器都被迫关机了，影响了业务稳定。其中一台已经不止一次自动重启。2、相关信息我们的宿主机使用的CentOS。如何确定它发生过自动重启？使用 last reboot命令可以看到每次系统启动的时间，即可看到那些计划外的重启时间。1）无故重启，首先想到的是查看物理机的/var/log/messages日志。但是在重启时间点附近没有找到与重启相关的信息。2）在/var/crash目录下，保存了内核crash的日志vmcore-dmesg.txt ，内核crash时会保存crash信息到这个文件中。日志的生成时间与宿主机重启时间一致，可以说明宿主机是发生了kernel crash然后导致的自动重启。3、问题分析从vmcore-dmesg日志中可以看到crash的堆栈：<2>kernel BUG at drivers/md/persistent-data/dm-btree-remove.c:181! <4>invalid opcode: 0000 [#1] SMP <4>last sysfs file: /sys/devices/system/cpu/online <4>CPU 13 <4>Modules linked in: bonding ip6_tables ebtable_nat ebtables ipt_REJECT ...继续阅读 (52)

1、引言"求孤的坐标…""谁看到月明了？""独嘉坐在哪里，我TT登陆不了！""有人看到我的土豪金了么？""有谁看到我的手机了么，白色经典版vivo音乐手机~~"随着蘑菇街人员越来越多，业务交互越来越频繁，以及新大楼的投入使用，经常出现找人找不到、移动设备忘记丢在哪里的情况；对于充满时尚和科技元素的蘑菇街，我们怎么能容忍"通讯基本靠吼，找人基本靠走"的尴尬局面？幸好幸好，有崇尚科技改变生活的工程师蓝狐君、语鬼君以及无所不能的大子腾。胡乱说了这么多，顿时感觉萌萌哒，那么下面开始吧。2、WIFI定位原理及实现我们在研究的过程中，先后采用了两种定位方法，三角定位法和指纹数据匹配定位法。2.1、三角定位法三角定位原理非常简单，GPS系统采用的基本原理也是三角定位法。即三点可以确定一个点。该方法分为两个阶段:2.1.1 基于RSSI的测距该方法的理论基础是:无线电信号强度随着传播距离的增加而衰减1，无线电传播距离与信号强度的关系。在大量实践的基础上可以得出，接收信号强度log-normal(对数-常态)分布模型，可以通过信号在传播过程中的衰减计算出传播距离。(1)其中Pl(d)为在距离d位置接收到的信号功率(单位dBm),Pl(d0)为距离为参考距离d0位置接收到的信号功率，一般取1m。n为信号衰减因子,为均值为0的高斯随机变量。接收端的信号强度:(2)基于实际情况及室内环境的因素，我们一般通 ...继续阅读 (35)

1、引言"求孤的坐标…""谁看到月明了？""独嘉坐在哪里，我TT登陆不了！""有人看到我的土豪金了么？""有谁看到我的手机了么，白色经典版vivo音乐手机~~"随着蘑菇街人员越来越多，业务交互越来越频繁，以及新大楼的投入使用，经常出现找人找不到、移动设备忘记丢在哪里的情况；对于充满时尚和科技元素的蘑菇街，我们怎么能容忍"通讯基本靠吼，找人基本靠走"的尴尬局面？幸好幸好，有崇尚科技改变生活的工程师蓝狐君、语鬼君以及无所不能的大子腾。胡乱说了这么多，顿时感觉萌萌哒，那么下面开始吧。2、WIFI定位原理及实现我们在研究的过程中，先后采用了两种定位方法，三角定位法和指纹数据匹配定位法。2.1、三角定位法三角定位原理非常简单，GPS系统采用的基本原理也是三角定位法。即三点可以确定一个点。该方法分为两个阶段:2.1.1 基于RSSI的测距该方法的理论基础是:无线电信号强度随着传播距离的增加而衰减1，无线电传播距离与信号强度的关系。在大量实践的基础上可以得出，接收信号强度log-normal(对数-常态)分布模型，可以通过信号在传播过程中的衰减计算出传播距离。(1)其中Pl(d)为在距离d位置接收到的信号功率(单位dBm),Pl(d0)为距离为参考距离d0位置接收到的信号功率，一般取1m。n为信号衰减因子,为均值为0的高斯随机变量。接收端的信号强度:(2)基于实际情况及室内环境的因素，我们一般通 ...继续阅读 (24)

搜索平台化中预热的需求描述为：当线上集群需要水平扩容时，新部署实例的机器需要用已存在的日志进行预查询，其目的是将用户的常用查询加载到扩容机内存中，最终对外开放时以提高缓存命中率，减少搜索RT比如现在要用A机器上的日志对B机器进行预热，实现很简单：步骤一、拿到A机器上的日志，%TOMCAT_HOME%/logs/catalina.2014-06-21.log默认取昨天生成好的日志文件，不存在就向前推，直到找不到报错。然后对日志文件过滤awk -F'{|}' '{/param/; if (count>100000) exit; if ($2 != "") {count++; print $2 > "preload.log";};}' catalina.2014-06-21.log其中用关键字“param”过滤行文本，再以分隔符“{”或“}”解析后将第二个字段重定向到preload.log文件下，取前10万行处理结果得到preload.log如下步骤二、将A机器上生成的preload.log文件scp到平台机，通过平台机读取文件并向B机器查询，代码如首先读取文件到到内存private List readPreloadFile(File preloadLog) { List ret = Lists.newArrayList(); BufferedReader br = ...继续阅读 (22)

搜索平台化中预热的需求描述为：当线上集群需要水平扩容时，新部署实例的机器需要用已存在的日志进行预查询，其目的是将用户的常用查询加载到扩容机内存中，最终对外开放时以提高缓存命中率，减少搜索RT比如现在要用A机器上的日志对B机器进行预热，实现很简单：步骤一、拿到A机器上的日志，%TOMCAT_HOME%/logs/catalina.2014-06-21.log默认取昨天生成好的日志文件，不存在就向前推，直到找不到报错。然后对日志文件过滤awk -F'{|}' '{/param/; if (count>100000) exit; if ($2 != "") {count++; print $2 > "preload.log";};}' catalina.2014-06-21.log其中用关键字“param”过滤行文本，再以分隔符“{”或“}”解析后将第二个字段重定向到preload.log文件下，取前10万行处理结果得到preload.log如下步骤二、将A机器上生成的preload.log文件scp到平台机，通过平台机读取文件并向B机器查询，代码如首先读取文件到到内存private List readPreloadFile(File preloadLog) { List ret = Lists.newArrayList(); BufferedReader br = ...继续阅读 (17)

##概述为了增加程序的可扩展性，以及降低后期维护的成本，在MAC TT的开发后期，我决定重构TT的网络层。重构之后的网络层实例化了网络请求，这样有一个好处就是方便维护网络请求的生命周期。每一个网络请求都把自己的数据打包和解包封装起来。换一种说法就是每个网络请求都是相互独立的。相对于之前把数据打包放在一个PackManager中，把解包的操作分发到UserModule和MessageModule等module中的做法更加解耦，后期想添加一种新的网络请求时可以做到对原先的代码原封不动，新的网络层通过block将发包和收包帮到了一块儿。这样一来开发者在函数的生命周期中就可以对收到的包做相应的处理，而不需要用通知在程序的某个阴暗角落做不为人知的处理。因为在整个程序中我们有很多中的网络请求，如果用通知的话，我们至少要添加相同种类的通知，在很大程度上增加了程序的复杂度以及维护成本，完成这一优化更多的是依靠block的特性。新的网络层框架保证了数据包的一致性，协议头中有seqNo，用于保证数据包的一致性。原先的网络层只管发送数据包，缺少了对返回数据包协议头的校验。假设这样一个场景A发送了两个获取用户信息的数据包a1和a2，这时服务器端会返回两个数据包b1和b2。原先的网络层这时是没法知道哪个数据包对应的是哪个数据包的。新的网络层协议将seqNo作为请求生命周期维护的标识符组成部分，在收到数据包的 ...继续阅读 (28)

##概述为了增加程序的可扩展性，以及降低后期维护的成本，在MAC TT的开发后期，我决定重构TT的网络层。重构之后的网络层实例化了网络请求，这样有一个好处就是方便维护网络请求的生命周期。每一个网络请求都把自己的数据打包和解包封装起来。换一种说法就是每个网络请求都是相互独立的。相对于之前把数据打包放在一个PackManager中，把解包的操作分发到UserModule和MessageModule等module中的做法更加解耦，后期想添加一种新的网络请求时可以做到对原先的代码原封不动，新的网络层通过block将发包和收包帮到了一块儿。这样一来开发者在函数的生命周期中就可以对收到的包做相应的处理，而不需要用通知在程序的某个阴暗角落做不为人知的处理。因为在整个程序中我们有很多中的网络请求，如果用通知的话，我们至少要添加相同种类的通知，在很大程度上增加了程序的复杂度以及维护成本，完成这一优化更多的是依靠block的特性。新的网络层框架保证了数据包的一致性，协议头中有seqNo，用于保证数据包的一致性。原先的网络层只管发送数据包，缺少了对返回数据包协议头的校验。假设这样一个场景A发送了两个获取用户信息的数据包a1和a2，这时服务器端会返回两个数据包b1和b2。原先的网络层这时是没法知道哪个数据包对应的是哪个数据包的。新的网络层协议将seqNo作为请求生命周期维护的标识符组成部分，在收到数据包的 ...继续阅读 (28)

Linux HugePage for MySQL Server(MySQL中大页的使用)网上大页的资料抄来抄去, 没一个是正确的 :shock: . 本人经过查Linux说明和实践, 现将线上的配置总结一下. :lol:效果对比未配置HugePage:配置HugePage后 (并加多客户端个数向MySQL施压):总结: 从对比数据看出来,开启HugePage后,QPS 2~3倍,提升下, UserCPU状态只是多消耗0.2~0.5而已.  Load低成3~5倍. 长短时间的运行,表情都很稳定. 大幅度减少重启后MySQL预热时间(Hit列提高几个百分点).原理资料大家知道,OS HugePage开启后,内存置换大幅度减少.这没什么高深的技术难度,但是很考验原理的理解和配置项的细心程度.linux kernel描述https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt*HugePages_Total is the size of the pool of huge pages. *HugePages_Free is the number of huge pages in the pool that are not yet allocated. *HugePages_Rsvd is short f ...继续阅读 (25)

Linux HugePage for MySQL Server(MySQL中大页的使用)网上大页的资料抄来抄去, 没一个是正确的 :shock: . 本人经过查Linux说明和实践, 现将线上的配置总结一下. :lol:效果对比未配置HugePage:配置HugePage后 (并加多客户端个数向MySQL施压):总结: 从对比数据看出来,开启HugePage后,QPS 2~3倍,提升下, UserCPU状态只是多消耗0.2~0.5而已.  Load低成3~5倍. 长短时间的运行,表情都很稳定. 大幅度减少重启后MySQL预热时间(Hit列提高几个百分点).原理资料大家知道,OS HugePage开启后,内存置换大幅度减少.这没什么高深的技术难度,但是很考验原理的理解和配置项的细心程度.linux kernel描述https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt*HugePages_Total is the size of the pool of huge pages. *HugePages_Free is the number of huge pages in the pool that are not yet allocated. *HugePages_Rsvd is short f ...继续阅读 (57)

前端MV*设计模式作为SPA(single page application)比较成熟的解决方案，在很多应用场景下被广泛运用。数据模型驱动的优势不言而喻，我们可以清晰的划分服务端数据与交互表现，更多关注前端模块层级之间的逻辑处理，拥有更好的可维护性和扩展性。然而模块化的层级结构让MV*和通常意义上的前端页面相比显得非常臃肿，一个MV*的组织架构可以将项目提升到App级别，所以MV*的选用使应用更加系统化的同时也失去了一些灵活性。Web-IM有着比较明显映射的数据模型，前有响应用户的富应用交互模式，后与服务端数据通讯有着多种链接模式，模块结构划分比较明显，MV*的使用可以更好的处理这三者之间的关系。数据模块，界面模块这两个必不可少，考虑到与服务端的通讯涉及到flash socket、ajax poll多套链接（将来还可能扩展更多链接方式，如websocket），所以把服务端细化到应用接口层，包括socket调用接口、回调接口和控制接口操作的socket交互模块，由socket交互模块来实现不同的连接方式，不同连接方式公用调用接口和回调接口，走相同的接口调用，然后加上一个相当于控制器的模块把前面所有模块联系起来，先称其为通知模块，负责模块间的连接，最后再加上前端神级模块util，我们就可以组装起一个基于MV*思想的Web-IM。/** * MOGU.IM.Data ...继续阅读 (23)

前端MV*设计模式作为SPA(single page application)比较成熟的解决方案，在很多应用场景下被广泛运用。数据模型驱动的优势不言而喻，我们可以清晰的划分服务端数据与交互表现，更多关注前端模块层级之间的逻辑处理，拥有更好的可维护性和扩展性。然而模块化的层级结构让MV*和通常意义上的前端页面相比显得非常臃肿，一个MV*的组织架构可以将项目提升到App级别，所以MV*的选用使应用更加系统化的同时也失去了一些灵活性。Web-IM有着比较明显映射的数据模型，前有响应用户的富应用交互模式，后与服务端数据通讯有着多种链接模式，模块结构划分比较明显，MV*的使用可以更好的处理这三者之间的关系。数据模块，界面模块这两个必不可少，考虑到与服务端的通讯涉及到flash socket、ajax poll多套链接（将来还可能扩展更多链接方式，如websocket），所以把服务端细化到应用接口层，包括socket调用接口、回调接口和控制接口操作的socket交互模块，由socket交互模块来实现不同的连接方式，不同连接方式公用调用接口和回调接口，走相同的接口调用，然后加上一个相当于控制器的模块把前面所有模块联系起来，先称其为通知模块，负责模块间的连接，最后再加上前端神级模块util，我们就可以组装起一个基于MV*思想的Web-IM。/** * MOGU.IM.Data ...继续阅读 (17)

#基于JAVA的简易缓存系统##背景几乎任何一个应用，特别是WEB应用，缓存都是非常重要的一块内容，在过去的一段PHP开发中，比较常见的使用缓存的例子如下：1、根据一个key从缓存中取值 2、如果取到值，则直接返回这个值 3、如果没取到值，则根据业务从solr或是db或是某一段业务逻辑中取值，然后再把这个key-value存入缓存以上步骤在每一个需要的地方都进行一遍。逻辑其实没有问题，代码跑起来也是OK的，就是看起来有点ugly，不够优雅，扩展性也不好。正好现在在做一个基于JAVA的WEB应用，可以对缓存做一次改造##实现首先，缓存有很多种，本地堆内内存，堆外缓存，redis，memcached等等，所以很容易的会想到构建一个超类，并且有put, get等：public abstract class Cache {public abstract void put(String key, Object object); public abstract Object get(String key);}这里假定key都是String类型的，另外应该还有一个缓存管理的功能，可以方遍查询缓存，删除缓存，清空缓存等，所以再加上几个方法：public abstract void remove(String key);public abstract void clear(); /** * 获 ...继续阅读 (24)

###1. 架构总览###2. 模块介绍####2.1 协议封装与任务流程#####1) 协议与任务的封装a. 协议有协议头(协议头因为格式相同，被抽象出来)和协议体组成，协议有两类：请求协议(request)和回复协议(response)； b. 任务(action)由请求协议、回复协议和任务回调(callback)组成； c. callback是针对客户端主动请求协议的相应处理，分别是成功回调、超时回调和失败回调；#####2) 消息(任务)流程a. 由UI或SYSTEM触发一个消息的生成，随之将其投递到发送队列中，等待发送； b. 消息发送线程会不停的从发送队列中拉取一个消息并发送出去，同时放入超时监测队列；而当网络断开时会等待若干时间并重新循环，若检测该消息在队列等待时间过长，则丢弃该消息并触发相应的失败回调； d. 对于客户端主动请求，在收到服务端给予回复时，调用该消息的成功回调处理相应回复； e. 对于超时线程监测超时的消息，移除超时监测队列，并调用超时回调。####2.2 定时任务定时任务的实现主要由TimerHelper类与ITimerProcessor两个类，第一个类主要实现了Timer的功能，ITimerProcessor为一个接口，当要建立一个Timer的时候，需要新建立一个类实现ITimerProcessor中得process接口来处理具体的业务。Tim ...继续阅读 (25)

IM服务器开发，从功能抽象的角度看可能非常简单，可以认为是管理大量的客户端连接和在不同的客户端之间传递消息，但具体到实现细节就比较复杂了。打个不恰当的比喻，OS的功能抽象也非常简单，无非是进程间的调度和硬件资源的管理，但要是自己去实现一个，一般人也就只能呵呵了。由于IM服务器里面的内容比较多，这个可以是一个系列的内容，所以这里只介绍服务器的架构以及为什么选择这样的架构我们的设计原则是保持简单，可以做一定的扩容，无单点故障。很多时候开发人员常犯的错误是过度设计和提前优化，"When in doubt, use brute force", 有时简单的方案才是最好的方案。架构设计需要考虑到服务器的业务逻辑和预计的用户量，比如同样的IM服务器设计，最高并发在线人数百万和千万的肯定有很大的不同， 如果按千万级别来设计一个只有百万级别的系统，增加的复杂度和工作量是非常可观的.目前我们的IM服务器架构设计的单机并发连接10万用户，总并发用户量可以达百万级，对于这样规模的服务器后台，可以采用很简单的架构来处理。有一个DispatchServer来分配客户端到一个消息服务器，消息服务器之间的数据交互通过一个中心的RouteServer来转发，和数据持久化层之间的交互由DBProxy服务器来处理.由于IM消息服务器和客户端之间交互非常频繁，但处理单个数据包的逻辑比较简单，没有IO或CPU密集型的操作， ...继续阅读 (19)