一直以来我们都比较缺乏一个易用的业务粒度的监控统计，故借鉴wechat的idkey系统来做了一个轻量级的AcOss系统。
我们在操作数据库的时候，可能会由于并发问题而引起的数据的不一致性（数据冲突）
乐观锁
乐观锁不是数据库自带的，需要我们自己去实现。乐观锁是指操作数据库时(更新操作)，想法很乐观，认为这次的操作不会导致冲突，在操作数据时，并不进行任何其他的特殊处理（也就是不加锁），而在进行更新后，再去判断是否有冲突了。
一、数据库事务隔离级别
数据库事务的隔离级别有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个部分加以说明.
