在我们的日常工作中，因为各种各样的原因，比如机器裁撤、业务重构等都会遇到数据迁移的情况，下面就谈谈数据迁移的几种常见方法。

介绍方法之前，我们先来谈谈数据迁移的几个原则：

1. 数据不能丢，不能错。数据的准确性、一致性、完整性是最基础的东西。
2. 服务尽可能不中断，
3. 数据迁移过程可以重入重迁。

一直以来我们都比较缺乏一个易用的业务粒度的监控统计，故借鉴wechat的idkey系统来做了一个轻量级的AcOss系统。

具备的功能

• 开发人员可以很方便的添加各种监控项，监控项可分为累加值、设置值、最大值与平局值四种类型
• 提供后台界面来申请idkey，id与key是两个概念，具体会在下文中给出。
• 提供后台界面来查看idkey的监控情况，一页展示所有的监控项目，最多128个。
• 每个监控项可以配置最大与最小阈值，超过阈值可以发送告警信息到负责人，告警可以在配置页面取消
• 因为是轻量级方案，并没有使用客户端部署agent的方式，而且采取集中往UDP Server发包，为了防止包量过大添加了采样率参数，对于分钟调用量万级别以上的接口强制设置采样率。在监控视图展示的时候会将数据反向放大回去。（项目初期可以使用默认值1，即100%采样）
  阅读全文 »

我们在操作数据库的时候，可能会由于并发问题而引起的数据的不一致性（数据冲突）

乐观锁
乐观锁不是数据库自带的，需要我们自己去实现。乐观锁是指操作数据库时(更新操作)，想法很乐观，认为这次的操作不会导致冲突，在操作数据时，并不进行任何其他的特殊处理（也就是不加锁），而在进行更新后，再去判断是否有冲突了。

一、数据库事务隔离级别

数据库事务的隔离级别有4个，由低到高依次为Read uncommitted 、Read committed 、Repeatable read 、Serializable ，这四个级别可以逐个解决脏读 、不可重复读 、幻读 这几类问题。

√: 可能出现 ×: 不会出现

|隔离级别|脏读| 不可重复读| 幻读|
|-|-|-|
|Read uncommitted |√| √ |√|
|Read committed |×| √ |√|
|Repeatable read| × |×|√|
|Serializable| × |× |×|

1. 强者愈强，弱者愈弱，马太效应明显，腾讯系、阿里系、百度系、头条系、新浪系占据了中国网民的绝大部分时间，后进者要么从垂直领域切入、要么改变自己的信息架构与技术架构才有一些机会。当然科技发展的同时也会产生一些蓝海区域，快速的把握时代发展就更加重要了。

   阅读全文 »

一眨眼两个月的时间就过去了，两个月来一直忙于接手业务、熟悉业务、熟悉代码，也没有时间进行总结与回顾，没有想到真正要回顾的时候就已经要离开了。

路线

广州->深圳->香港->大阪->京都->东京->香港->深圳->广州

系统架构能力

1.基本理论

扩展性设计

架构易于扩展是其非常重要的一个特性，好的架构需要有非常强的扩展能力，架构中的每个角色都需要有standby，好的架构可以满足业务飞速发展的需要，传说中QQ的架构好多年都没有大变，满足了用户从百万、千万、亿级的发展需要。我自己写的AcMid和reviewTask工程就是具备多机多进程的消费模型，通过队列进行生产者与消费者的解耦，也是可以无限添加机器与进程的架构。

可用性设计

好的架构都是非常注重可用性的，好的架构可以极大的提高系统的可用性。好的架构是一整套方案，所以可用性是非常高的。

可靠性设计

用于定义组件或系统可靠性的一个度量标准是平均故障间隔时间 (MTBF)。MTBF 是平均间隔时间。好的架构需要易监控、会有全套的业务日志打出，这样整个系统会比较定位问题，而且容灾完全可以让架构更可靠。

一致性设计

在海量服务的时代，单台机器是Hold不住的，所以我们的系统都是分布式的系统，一致性就是特指的数据一致性，也就是存储一致性。一致性有时候没有那么严格，海量服务时代大部分的需求实现最终一致性就行了。CAP定理告诉我们三者不能兼得，P是必须要保证的，所以只能牺牲一定的C来保证A。

负载均衡设计

负载均衡是架构设计中非常重要的一环，就如上面提到的，海量服务之道与分布式架构是捆绑在一起的，既然是分布式的，就不然存在非常多的机器来协同工作，如果平衡各个模块的负载就非常的重要，希望流量可以均衡的分配在下游的模块中（需要考虑到下游模块的负载），负载均衡的方法有很多，我个人觉得L5的设计师非常的赞的，几年前就预感其会普遍流行起来的。

过载保护设计

好的架构不是提供尽力而为的服务，而是提供量力而为的服务。好的架构一定有一个容量与负载边界，超过这个边界后系统开始出现问题，有的架构在此时会产生雪崩，服务完全不可用。过载保护就像是给系统加一个保险，始终将服务的量级控制在自己的能力之内。我们目前的架构不具备过载保护，所以动漫目前的架构不是一个好的架构。

灾难恢复与备份

容灾是架构最开始就需要考虑的一个点，架构不允许出现单点的情况。目前很多的海量系统都设计为多地部署，所以灾难恢复不是什么难题，最要紧的部分就是存储，网上经常爆出程序员离职后格式化数据库，那么存储组件的备份一定要做好，每天都需要备份，然后线上也需要存储多个副本。

2.协议设计

文本协议

如果是http服务的话，文本协议比较好。http+json是非常多服务的标配，文本协议具备简单、可读性高等特性。文本协议在配置方面也应用广泛。

二进制协议

二进制协议体积小、效率高，在数据传输方面有极大的优势，所以是数据传输格式的首选，不过因为二进制协议可读性不高，所以还需要配套使用一些解析工具。

3.接入层架构设计

DNS轮询

目前DNS轮询是接入层采用的比较多的一种方式了，不过DNS轮询比较大的问题是的配置存在ttl。

动静态分离

快慢分离、动静分离是好的架构需要具备的特性。动态请求与静态请求分开处理，静态请求是十分适合CDN的，分发至离用户更近的OC节点，可以为用户提供更好的服务。不过貌似目前动态请求也可以放在CDN了，该动态值得关注。

静态化

静态化的并发肯定比动态请求更高

一直都有看InfoQ上面的各种技术文章，感觉InfoQ算是国内组织技术会议与传播技术做的比较好的了，所以其组织的各种大会一直以来都想去参加，但是限于门票比较贵与路费就没有动买票参会的念头。正好组织要在北京开UP大会，所以组内有几个名额可以去参加下QCon2018在北京站点的全球软件开发者大会，我运气好，获得了一张票。