一、数据库事务隔离级别
数据库事务的隔离级别有4个，由低到高依次为Read uncommitted 、Read committed 、Repeatable read 、Serializable ，这四个级别可以逐个解决脏读 、不可重复读 、幻读 这几类问题。
√: 可能出现 ×: 不会出现
|隔离级别|脏读| 不可重复读| 幻读|
|-|-|-|
|Read uncommitted |√| √ |√|
|Read committed |×| √ |√|
|Repeatable read| × |×|√|
|Serializable| × |× |×|
强者愈强，弱者愈弱，马太效应明显，腾讯系、阿里系、百度系、头条系、新浪系占据了中国网民的绝大部分时间，后进者要么从垂直领域切入、要么改变自己的信息架构与技术架构才有一些机会。当然科技发展的同时也会产生一些蓝海区域，快速的把握时代发展就更加重要了。
架构易于扩展是其非常重要的一个特性，好的架构需要有非常强的扩展能力，架构中的每个角色都需要有standby，好的架构可以满足业务飞速发展的需要，传说中QQ的架构好多年都没有大变，满足了用户从百万、千万、亿级的发展需要。我自己写的AcMid和reviewTask工程就是具备多机多进程的消费模型，通过队列进行生产者与消费者的解耦，也是可以无限添加机器与进程的架构。
好的架构都是非常注重可用性的，好的架构可以极大的提高系统的可用性。好的架构是一整套方案，所以可用性是非常高的。
用于定义组件或系统可靠性的一个度量标准是平均故障间隔时间 (MTBF)。MTBF 是平均间隔时间。好的架构需要易监控、会有全套的业务日志打出，这样整个系统会比较定位问题，而且容灾完全可以让架构更可靠。
在海量服务的时代，单台机器是Hold不住的，所以我们的系统都是分布式的系统，一致性就是特指的数据一致性，也就是存储一致性。一致性有时候没有那么严格，海量服务时代大部分的需求实现最终一致性就行了。CAP定理告诉我们三者不能兼得，P是必须要保证的，所以只能牺牲一定的C来保证A。
负载均衡是架构设计中非常重要的一环，就如上面提到的，海量服务之道与分布式架构是捆绑在一起的，既然是分布式的，就不然存在非常多的机器来协同工作，如果平衡各个模块的负载就非常的重要，希望流量可以均衡的分配在下游的模块中（需要考虑到下游模块的负载），负载均衡的方法有很多，我个人觉得L5的设计师非常的赞的，几年前就预感其会普遍流行起来的。
好的架构不是提供尽力而为的服务，而是提供量力而为的服务。好的架构一定有一个容量与负载边界，超过这个边界后系统开始出现问题，有的架构在此时会产生雪崩，服务完全不可用。过载保护就像是给系统加一个保险，始终将服务的量级控制在自己的能力之内。我们目前的架构不具备过载保护，所以动漫目前的架构不是一个好的架构。
容灾是架构最开始就需要考虑的一个点，架构不允许出现单点的情况。目前很多的海量系统都设计为多地部署，所以灾难恢复不是什么难题，最要紧的部分就是存储，网上经常爆出程序员离职后格式化数据库，那么存储组件的备份一定要做好，每天都需要备份，然后线上也需要存储多个副本。
如果是http服务的话，文本协议比较好。http+json是非常多服务的标配，文本协议具备简单、可读性高等特性。文本协议在配置方面也应用广泛。
二进制协议体积小、效率高，在数据传输方面有极大的优势，所以是数据传输格式的首选，不过因为二进制协议可读性不高，所以还需要配套使用一些解析工具。
目前DNS轮询是接入层采用的比较多的一种方式了，不过DNS轮询比较大的问题是的配置存在ttl。
快慢分离、动静分离是好的架构需要具备的特性。动态请求与静态请求分开处理，静态请求是十分适合CDN的，分发至离用户更近的OC节点，可以为用户提供更好的服务。不过貌似目前动态请求也可以放在CDN了，该动态值得关注。
静态化的并发肯定比动态请求更高
一直都有看InfoQ上面的各种技术文章，感觉InfoQ算是国内组织技术会议与传播技术做的比较好的了，所以其组织的各种大会一直以来都想去参加，但是限于门票比较贵与路费就没有动买票参会的念头。正好组织要在北京开UP大会，所以组内有几个名额可以去参加下QCon2018在北京站点的全球软件开发者大会，我运气好，获得了一张票。
在我们的日常开发过程中，少不了需要提供服务给比人使用，可能是一个接口，也可能是一个服务。我们当然希望我们提供的服务具备低延迟、高并发的特点，那么从哪些地方可以优化我们的程序或者说是服务呢？
该部分分14个部分加以说明.
我知道A/B Test还是从几年前的一位女产品经理那里听到的，然后专门去搜索了一下这到底是个什么东西，才对它有个大概的认识。前些时间看了一些文章说今日头条与国外的一些游戏公司搭建了一套系统，能够非常方便的使用A/B测试来推出新的功能，看到这个的时候我自己挺震惊的，没有想到A/B测试还可以这么玩啊。
就是说对于一个需求有存在大于一种方案的时候（一般会有两种方案），每种方案都有优缺点但是难以取舍，即方案A与方案B，从整体用户中挑选样本量相同的两组样本，一组应用方案A，另外一种应用方案B。然后在一定的观察周期后（基本是1到2周吧），观察两组方案的数据指标，数据优的那个方案就可以合入到主干版本中去全量发行了。
背景：在日常开发的过程中，开发更多的关注在功能开发上，对于接口性能与服务能力关注较少，但是无论是对内还是对外提供接口与服务，都应该明白的给出服务能力界限的说明，而且需要对方给出调用量的评估，这样才能在一定程度上做到心中有数，从而维护系统的安全。压测系统不是一蹴而就的，据了解业内大公司的压测系统基本经过了几轮迭代，而且耗时基本需要3年。
压测系统的设计最后会走上类似阿里双十一、微信等全链路压测的道路，但是这两个系统都是花费了至少3年的时间打磨完成，所以我们也分四大步走：
1.提供压测的url、ip+port+协议栈 +参数，来进行简单的分布式压测，（预期完成时间2018年上半年)
2.改造目前项目的上下游路由机制（目前使用的是L５，但是L５不具备准备的流量分配机制），使得能方便快速的切换流量到单台机器上，从而得出单台机器的负载上限。（预期完成时间2018年下半年)
3.复制目前项目单日所有用户的流量，清洗后进行重放，来大规模的压测整个系统，目的是在大流量的压力下发现系统瓶颈与隐藏故障点。（预期完成时间2019年全年)
4.压测常规化，定时的来进行流量压测，完成自动化压测系统的进化。（预期完成时间2020年上半年)
压测大师可以很方便的实现第一步，但是具备如下缺点：
1.被压测机器的负载不能很方便的展示出来，最关键的是需要在被压测机器上装个软件，路径较长
2.压测大师对每个Url的并发上限为200，虽然可以通过开启白名单的方式来提升，但是感觉还是不太方便。
3.最主要的一点是，压测大师是一个独立的系统，虽然能大概cover住我们的第一步，但是对于我们的长期目标来说并不能很好的满足。
模块介绍：
web controler: 显示与控制模块，显示压测的结果数据与agent的负载数据、agent的状态数据、dispatch模块的分发状态。
Manager：任务管理模块，通过从web controler获取任务配置，然后进行任务分配与启动停止。
Register: agent节点注册模块，可以获取agent的空闲繁忙状态，一般是分布式节点，推荐使用zk
dispatch: 文件分发模块，将提交的任务文件通过dispatch模块分发到各agent机器中。
agent: 真实的压测发起模块，从dispatch模块获取压测文件，从manager获取启停命令。
monitor: 监控统计模块，agent的负载信息上报至monitor模块。
MQ: agent获取压测结果，将其写入MQ
Collector: 收集器模块，将压测结果与agent的负载信息汇聚处理。
DB/DR：信息储存模块，存储web controler需要显示的各项数据。
1.能模拟线上流量（真实请求回放、自己模拟请求）
2.能区分模拟流量与真实流量
3.在线压测
4.物理隔离存储 正常存储+影子存储
5.能快速的进行流量路由，将单个模块的请求打满，直到错误率上升为止，因为具备重试的逻辑，所以问题不是很大。
有赞
http://www.infoq.com/cn/articles/youzan-11-11-stress-testing
云集
https://github.com/yunjiweidian/TITAN
滴滴
http://gitbook.cn/books/58edf24902c60a2473618fac/index.html
