10大高性能开发宝石，我要消灭一半程序员( 三 ) _高性能开发

文章插图

序列化简单来说，是将内存中的对象转换成可以传输和存储的数据，而这个过程的逆向操作就是反序列化。序列化 && 反序列化技术可以实现将内存对象在本地和远程计算机上搬运。好比把大象关进冰箱门分三步：

将本地内存对象编码成数据流
通过网络传输上述数据流
将收到的数据流在内存中构建出对象

序列化技术有很多免费开源的框架，衡量一个序列化框架的指标有这么几个：

是否支持跨语言使用，能支持哪些语言
是否只是单纯的序列化功能，包不包含RPC框架
序列化传输性能
扩展支持能力(数据对象增删字段后，前后的兼容性)
是否支持动态解析(动态解析是指不需要提前编译，根据拿到的数据格式定义文件立即就能解析)

下面流行的三大序列化框架protobuf、thrift、avro的对比：
ProtoBuf：
厂商：google
支持语言：C++、Java、Python等
动态性支持：较差，一般需要提前编译
是否包含RPC：否
简介：ProtoBuf是谷歌出品的序列化框架，成熟稳定，性能强劲，很多大厂都在使用。自身只是一个序列化框架，不包含RPC功能，不过可以与同是Google出品的GPRC框架一起配套使用，作为后端RPC服务开发的黄金搭档。

文章插图

缺点是对动态性支持较弱，不过在更新版本中这一现象有待改善。总体来说，ProtoBuf都是一款非常值得推荐的序列化框架。
Thrift
厂商：Facebook
支持语言：C++、Java、Python、PHP、C#、Go、JavaScript等
【10大高性能开发宝石，我要消灭一半程序员】动态性支持：差
是否包含RPC：是
简介：这是一个由Facebook出品的RPC框架，本身内含二进制序列化方案，但Thrift本身的RPC和数据序列化是解耦的，你甚至可以选择XML、JSON等自定义的数据格式。在国内同样有一批大厂在使用，性能方面和ProtoBuf不分伯仲。缺点和ProtoBuf一样，对动态解析的支持不太友好。
Avro
支持语言：C、C++、Java、Python、C#等
动态性支持：好
是否包含RPC：是
简介：这是一个源自于Hadoop生态中的序列化框架，自带RPC框架，也可独立使用。相比前两位最大的优势就是支持动态数据解析。

文章插图

为什么我一直在说这个动态解析功能呢?在之前的一段项目经历中，轩辕就遇到了三种技术的选型，摆在我们面前的就是这三种方案。需要一个C++开发的服务和一个Java开发的服务能够进行RPC 。
Protobuf和Thrift都需要通过“编译”将对应的数据协议定义文件编译成对应的C++/Java源代码，然后合入项目中一起编译，从而进行解析。
当时，Java项目组同学非常强硬的拒绝了这一做法，其理由是这样编译出来的强业务型代码融入他们的业务无关的框架服务，而业务是常变的，这样做不够优雅。
最后，经过测试，最终选择了AVRO作为我们的方案。Java一侧只需要动态加载对应的数据格式文件，就能对拿到的数据进行解析，并且性能上还不错。(当然，对于C++一侧还是选择了提前编译的做法)
自从你的网站支持了动态能力，免不了要和数据库打交道，但随着用户的增长，你发现数据库的查询速度越来越慢。
这个时候，你需要：
数据库索引技术
想想你手上有一本数学教材，但是目录被人给撕掉了，现在要你翻到讲三角函数的那一页，你该怎么办?
没有了目录，你只有两种办法，要么一页一页的翻，要么随机翻，直到找到三角函数的那一页。
对于数据库也是一样的道理，如果我们的数据表没有“目录”，那要查询满足条件的记录行，就得全表扫描，那可就恼火了。所以为了加快查询速度，得给数据表也设置目录，在数据库领域中，这就是索引。
一般情况下，数据表都会有多个字段，那根据不同的字段也就可以设立不同的索引。
索引的分类

主键索引
聚集索引
非聚集索引

主键我们都知道，是唯一标识一条数据记录的字段(也存在多个字段一起来唯一标识数据记录的联合主键)，那与之对应的就是主键索引了。
聚集索引是指索引的逻辑顺序与表记录的物理存储顺序一致的索引，一般情况下主键索引就符合这个定义，所以一般来说主键索引也是聚集索引。但是，这不是绝对的，在不同的数据库中，或者在同一个数据库下的不同存储引擎中还是有不同。