语法
& : 按位与，二进制位同时都为1的位设为1。
| : 按位或，二进制位有一个位为1就为1.
^ : 位异或，对应位的二进制数不同时，对应位的结果才为1；如果两个对应位数都为0或者都为1，则对应位的结果为0。
原理
1 | $a = 6 转化为2进制为 110 |
做秒杀的几个思路
秒杀业务为什么难做
- im系统，例如qq或者微博，每个人都读自己的数据（好友列表、群列表、个人信息）；
- 微博系统，每个人读你关注的人的数据，一个人读多个人的数据；
- 秒杀系统，库存只有一份，所有人会在集中的时间读和写这些数据，多个人读一个数据。
小米手机每周二的秒杀，可能手机只有1万部，但瞬时进入的流量可能是几百几千万。
12306抢票，票是有限的，库存一份，瞬时流量非常多，都读相同的库存。读写冲突，锁非常严重，这是秒杀业务难的地方。那我们怎么优化秒杀业务的架构呢？（其实12306比淘宝要更难做，因为所有的都是动态库存，几百种sku。有兴趣请点击查看）
优化方向
将请求尽量拦截在系统上游（不要让锁冲突落到数据库上去）。传统秒杀系统之所以挂，请求都压倒了后端数据层，数据读写锁冲突严重，并发高响应慢，几乎所有请求都超时，流量虽大，下单成功的有效流量甚小。以12306为例，一趟火车其实只有2000张票，200w个人来买，基本没有人能买成功，请求有效率为0。
充分利用缓存，秒杀买票，这是一个典型的读多些少的应用场景，大部分请求是车次查询，票查询，下单和支付才是写请求。一趟火车其实只有2000张票，200w个人来买，最多2000个人下单成功，其他人都是查询库存，写比例只有0.1%，读比例占99.9%，非常适合使用缓存来优化。
常见秒杀架构
- 浏览器端，最上层，会执行到一些JS代码
- 站点层，这一层会访问后端数据，拼html页面返回给浏览器
- 服务层，向上游屏蔽底层数据细节，提供数据访问
- 数据层，最终的库存是存在这里的，mysql是一个典型（当然还有会缓存）
各层次优化细节
客户端怎么优化（浏览器层，APP层）
- 产品层面，用户点击“查询”或者“购票”后，按钮置灰，禁止用户重复提交请求；
- JS层面，**限制用户**在x秒之内只能提交一次请求；
- APP层面，可以做类似的事情，虽然你疯狂的在摇微信，其实x秒才向后端发起一次请求。这就是所谓的“将请求尽量拦截在系统上游”，越上游越好，浏览器层，APP层就给拦住，这样就能挡住80%+的请求。
但是这种办法只能拦住普通用户（但99%的用户是普通用户）对于群内的高端程序员是拦不住的。firebug一抓包，http长啥样都知道，js是万万拦不住程序员写for循环，调用http接口的，这部分请求怎么处理？
站点层面的请求拦截
怎么拦截？怎么防止程序员写for循环调用，有去重依据么？ip？cookie-id？…想复杂了，这类业务都需要登录，用uid即可。在站点层面，对uid进行请求计数和去重，甚至不需要统一存储计数，直接站点层内存存储（这样计数会不准，但最简单）。一个uid，5秒只准透过1个请求，这样又能拦住99%的for循环请求。
5s只透过一个请求，其余的请求怎么办？
缓存，页面缓存，同一个uid，限制访问频度，做页面缓存，x秒内到达站点层的请求，均返回同一页面。
同一个item的查询，例如车次，做页面缓存，x秒内到达站点层的请求，均返回同一页面。如此限流，既能保证用户有良好的用户体验（没有返回404）又能保证系统的健壮性（利用页面缓存，把请求拦截在站点层了）。
页面缓存不一定要保证所有站点返回一致的页面，直接放在每个站点的内存也是可以的。优点是简单，坏处是http请求落到不同的站点，返回的车票数据可能不一样，这是站点层的请求拦截与缓存优化。
好，这个方式拦住了写for循环发http请求的程序员，有些高端程序员（黑客）控制了10w个肉鸡，手里有10w个uid，同时发请求（先不考虑实名制的问题，小米抢手机不需要实名制），这下怎么办，站点层按照uid限流拦不住了。
服务层来拦截（反正就是不要让请求落到数据库上去）
服务层怎么拦截？我是服务层，我清楚的知道小米只有1万部手机，我清楚的知道一列火车只有2000张车票，我透10w个请求去数据库有什么意义呢？没错， 请求队列！
对于写请求，做请求队列，每次只透有限的写请求去数据层（ 下订单，支付 这样的写业务）
1w部手机，只透1w个下单请求去db
3k张火车票，只透3k个下单请求去db
如果均成功再放下一批，如果库存不够则队列里的写请求全部返回“已售完”。
对于读请求，怎么优化？cache抗，不管是memcached还是redis，单机抗个每秒10w应该都是没什么问题的。如此限流，只有非常少的写请求，和非常少的读缓存mis的请求会透到数据层去，又有99.9%的请求被拦住了。
其他业务优化方面:
- 还有业务规则上的一些优化。回想12306所做的，分时分段售票，原来统一10点卖票，现在8点，8点半，9点，…每隔半个小时放出一批：将流量摊匀。
- 数据粒度的优化：你去购票，对于余票查询这个业务，票剩了58张，还是26张，你真的关注么，其实我们只关心有票和无票？流量大的时候，做一个
粗粒度的“有票”“无票”缓存即可。- 一些业务逻辑的异步：例如下单业务与 支付业务的分离。这些优化都是结合 业务 来的
数据库层
- 浏览器拦截了80%
- 站点层拦截了99.9%并做了页面缓存
- 服务层又做了写请求队列与数据缓存
每次透到数据库层的请求都是可控的,db基本就没什么压力了。库存是有限的，透这么多请求来数据库没有意义，全部透到数据库，100w个下单，0个成功，请求有效率0%。透3k个到数据，全部成功，请求有效率100%。
总体思路
- 尽量将请求拦截在系统上游（越上游越好）；
- 读多写少的常用多使用缓存（缓存抗读压力）；
- 浏览器和APP：做限速
- 站点层：按照uid做限速，做页面缓存
- 服务层：按照业务做写请求队列控制流量，做数据缓存
- 数据层：闲庭信步
其他的优化：
- 当还是有大量流量到了站点层了，用扩容；或着拦截或抛弃50%的请求，50%的请求直接返回稍后重试，不能让所有的用户都失败。
- 服务层可以使用队列，若队列已经有远超过库存的，在过来的请求就直接返回稍后重试。可以一个服务一个队列，总数/服务个数。如果同意一个队列的话，有并发锁的问题。
- 其他常见的场景，运营活动页面，短时间的推送消息，都可以做缓存。
- 下单不支付，过了等待时间“回仓”改库存。
- 如果同时进行的活动很多，需要垂直拆分
- 如果业务失败的话，直接返回重试，没必要再从新放入队列
- 数据和缓存不一致的时候，脏读了，只要数据库层面真实性没有问题，这个场景是可以容忍的。
flex布局
布局的传统解决方案，基于盒状模型，依赖 display属性 + position属性 + float属性。它对于那些特殊布局非常不方便，比如，垂直居中就不容易实现。
Flex是Flexible Box的缩写，意为”弹性布局”，用来为盒状模型提供最大的灵活性。
任何一个容器都可以指定为Flex布局。
怎么快速恢复数据？
YAML 语言教程
配置文件是软件不可缺少的部分，怎么写配置也是一门学问。
YAML 语言专门用来写配置文件，非常简洁和强大，远比 JSON 格式方便和灵活。
npm-script
vagrant usage
VirtualBox， Vagrant
安装VirtualBox, 安装vagrant
安装Box
你可以把它想成是一个箱子，里面装了一些东西。在用 Vagrant 创建虚拟机的时候，需要用到 Box ，它里面会包装操作系统的镜像，不同的 Box 带的操作系统可能是不一样的，比如 CentOS，Ubuntu 等等，你可以基于它们去创建自己版本的 Box，比如在虚拟机上安装一些软件，然后把它重新打包成 Box。
在 vagrant添加 Box ，Vagrant 提供的云服务 ,要把 Box 下载到本地的电脑上，交给 Vagrant 去管理，这样在创建虚拟机的时候，Vagrant 会复制一份你指定的 Box 到你的项目里面，这样你在这个虚拟机上的操作，就不会影响到其它的项目。
shell 相关
记录一些用shell编写的小脚本，等等。
MangoDB 学习指南
安装篇
下载安装
1 | curl -O https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-rhel62-3.2.10.tgz |
mysql-cheatsheet
Connect/Disconnect
1 | mysql -h <host> -u <user> -p<passwd> |