语法
& : 按位与,二进制位同时都为1的位设为1。
| : 按位或,二进制位有一个位为1就为1.
^ : 位异或,对应位的二进制数不同时,对应位的结果才为1;如果两个对应位数都为0或者都为1,则对应位的结果为0。
原理
1 | $a = 6 转化为2进制为 110 |
升级自己的操作系统
& : 按位与,二进制位同时都为1的位设为1。
| : 按位或,二进制位有一个位为1就为1.
^ : 位异或,对应位的二进制数不同时,对应位的结果才为1;如果两个对应位数都为0或者都为1,则对应位的结果为0。
1 | $a = 6 转化为2进制为 110 |
小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万。
12306抢票,票是有限的,库存一份,瞬时流量非常多,都读相同的库存。读写冲突,锁非常严重,这是秒杀业务难的地方。那我们怎么优化秒杀业务的架构呢?(其实12306比淘宝要更难做,因为所有的都是动态库存,几百种sku。有兴趣请点击查看)
将请求尽量拦截在系统上游(不要让锁冲突落到数据库上去)。传统秒杀系统之所以挂,请求都压倒了后端数据层,数据读写锁冲突严重,并发高响应慢,几乎所有请求都超时,流量虽大,下单成功的有效流量甚小。以12306为例,一趟火车其实只有2000张票,200w个人来买,基本没有人能买成功,请求有效率为0。
充分利用缓存,秒杀买票,这是一个典型的读多些少的应用场景,大部分请求是车次查询,票查询,下单和支付才是写请求。一趟火车其实只有2000张票,200w个人来买,最多2000个人下单成功,其他人都是查询库存,写比例只有0.1%,读比例占99.9%,非常适合使用缓存来优化。
- 产品层面,用户点击“查询”或者“购票”后,按钮置灰,禁止用户重复提交请求;
- 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做限速,做页面缓存
- 服务层:按照业务做写请求队列控制流量,做数据缓存
- 数据层:闲庭信步
布局的传统解决方案,基于盒状模型,依赖 display属性 + position属性 + float属性。它对于那些特殊布局非常不方便,比如,垂直居中就不容易实现。
Flex是Flexible Box的缩写,意为”弹性布局”,用来为盒状模型提供最大的灵活性。
任何一个容器都可以指定为Flex布局。
配置文件是软件不可缺少的部分,怎么写配置也是一门学问。
YAML 语言专门用来写配置文件,非常简洁和强大,远比 JSON 格式方便和灵活。
安装VirtualBox, 安装vagrant
你可以把它想成是一个箱子,里面装了一些东西。在用 Vagrant 创建虚拟机的时候,需要用到 Box ,它里面会包装操作系统的镜像,不同的 Box 带的操作系统可能是不一样的,比如 CentOS,Ubuntu 等等,你可以基于它们去创建自己版本的 Box,比如在虚拟机上安装一些软件,然后把它重新打包成 Box。
在 vagrant添加 Box
,Vagrant 提供的云服务 ,要把 Box 下载到本地的电脑上,交给 Vagrant 去管理,这样在创建虚拟机的时候,Vagrant 会复制一份你指定的 Box 到你的项目里面,这样你在这个虚拟机上的操作,就不会影响到其它的项目。
记录一些用shell编写的小脚本,等等。
1 | curl -O https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-rhel62-3.2.10.tgz |
1 | mysql -h <host> -u <user> -p<passwd> |