天气变化无常的一周---4.10周技术小结(二)

感觉每一篇总结文章不适合放太多的内容,否则读起来的话,有些累,而且会比较索然无味。(当然可能也和自己写的文章水平有关吧,哈哈哈)
接着上篇的总结,继续再总结、梳理几个问题:
目录

1.行/列数据库 关系型/非关系型数据库
2.SOA和微服务架构
3.网络I/O模型

1.行/列数据库 关系/非关系型数据库

1.1 行/列数据库

1.1.1 什么是行/列数据库

简单理解这两个概念:
行存储:一次写入一个完整的数据实体(包含了各种字段)
列存储:一次写入所有数据的一个属性
然后结合数据库软件计算机磁盘来理解这两个概念:无非就是数据库软件能够对外(即对操作者)提供相应的行/列数据库的设计接口,甚至是可视化界面接口。然后对内(即对计算机磁盘)进行行/列式的存储,即是按照每个实体来存储还是按照每个字段来存储。

1.1.2 它们各自的优缺点

行存储的优缺点:优点是对一个实体数据的写入/改修 性能很高,缺点是如果要对很多实体的某一属性进行操作,则会产生其他实体数据属性的冗余,而且在操作上的性能也很低
列存储的优缺点:优点是能操作很多实体的某些属性性能很高,但是对于完整实体的操作性能很低

1.1.3 它们的应用场景

应用场景则是根据它们各自的优缺点来进行灵活确定的。
但是目前对于大数据库的存储,操作主流做法都是基于列示存储的。

1.1.4 数据库代表

行式数据库的代表包括:传统的RDBMS
列式数据库的代表包括:SAP HANA、Amazon Redshift、Sybase IQ、ParAccel、Sand/DNA Analytics、Vertica、Aster Data Systems和greenplum等。

1.1.5 参考文章:

大数据存取的选择:行存储还是列存储?
数据库的方向 - 行vs列
对列式数据库的一点总结和展望
列式数据库-维基百科

1.2 关系/非关系型数据库

1.2.1 什么是关系/非关系型数据库

关系型数据库,即RDBMS,每个表是按照实体来设计的,是一个二维表格模型,并且需要遵循许多的设计约束
非关系型数据库,也叫做NOSQL数据库,它不要求每一条记录都是一个完整的实体,所以相对来说字段可以自由变化、扩展。
这两类就是不同数据库的规定,可以有关系,也可以没有关系(但并不绝对)。

1.2.2 它们各自的优缺点

关系型数据库:符合约束规范设计,能够很好地保证数据的完整性,一致性,减少数据冗余。
但是对于并发性能不好(主要原因就在于磁盘IO),对海量数据的操作息效率很低,扩展性较差(表具有固定的结构)。
非关系型数据库:以键值对存储,可以随意扩展,支持高并发,可以海量数据的访问,支持分布式扩展
但是不能很好地支持事务(即不具备完整的ACID)

1.2.3 它们的应用场景

关系型数据库:对事务要求高的,不用经常扩展的,并发量不高,对海量数据操作少。
非关系型数据库:高并发,海量数据操作,分布式架构

1.2.4 它们各自的代表

关系型数据库: Oracle, Sql Server, Access, Mysql
非关系型数据库: redis,mongoDB,memcached,

1.2.5 参考文章:

关系型数据库和非关系型数据库

2.SOA和微服务架构

首先来看一张它们的演变图:

SOA和微服务架构演变

2.1 传统SOA架构:

2.1.1 为什么会有传统SOA架构的产生

早期大型系统,比如ERP,OA,CRM等难以进行集成,故产生了SOA架构

2.1.2 传统SOA架构是怎样的

传统SOA架构

该架构有一个企业服务总线ESB,它的作用就是对外提供支持各种协议、粗粒度的服务接口,对内映射相应的服务。

2.1.3 传统SOA架构有什么优缺点

1.存在多种通讯协议,通讯方式复杂
2.ESB存在单点故障 隐患
3.开发代价很大

2.2 新型的SOA架构:

应用->服务,即应用直接调用外部服务,通讯协议一般为HTTP,数据格式一般为JSON

新型的SOA架构

2.3 微服务

优点:
简单连接:一般为HTTP + JSON
分散管理:可以单独编译,部署。
支持自由扩展
系统容错性高

微服务遇到的问题:
1.复杂的分布式系统通
2.分布式事务一致性

2.4 参考文章

重新理解微服务
每天都在谈SOA和微服务,但你真的理解什么是服务吗?
基于微服务的软件架构模式

3.网络I/O模型

总体来说分为两大类:同步和异步模型。

  • 同步模型
    • 阻塞I/O
    • 非阻塞I/O
    • 多路复用I/O
    • 信号驱动式I/O
  • 异步IO

网络I/O模型的过程:

网络I/O的本质是socket的读取,socket在linux系统被抽象为流,I/O可以理解为对流的操作。这个操作又分为两个阶段:

  • 等待流数据准备(wating for the data to be ready)。
  • 从内核向进程复制数据(copying the data from the kernel to the process)。

对于socket流而言:

第一步通常涉及等待网络上的数据分组到达,然后被复制到内核的某个缓冲区。
第二步把数据从内核缓冲区复制到应用进程缓冲区。

  • 阻塞I/O
阻塞I/O

首先用户空间的一个进程调用了recvfrom(系统调用方法),然后该方法被转移到内核空间中执行。注意当用户空间的进程执行了该方法,便进入阻塞状态。内核空间执行该方法,开始接受相应的数据,直接数据在内核空间准备就绪,这个时候将数据复制到用户空间,最后用户空间从recvfrom返回。

  • 非阻塞I/O
非阻塞I/O

内核中数据准备好之前,用户空间的进程不会阻塞,而是采用轮询方式来访问。

  • 多路复用I/O
多路复用I/O

用户空间进程调用select后阻塞,直到内核空间返回目前可用的可读条件,接着再读取内核空间的数据,此时又为阻塞。(需要注意的是内核空间返回的还可能是可写或异常条件)

  • 异步IO
异步IO

对于异步IO来说,感觉一切都显得那么简单残暴。用户空间调用read方法,然后内核直接返回,此时用户空间继续执行接下来的代码,而不用阻塞在这里。当用户空间数据准备就绪,就从内核返回一个信号通知最后的结果。

个人对同步/异步,阻塞/非阻塞的理解
对于阻塞/非阻塞的描述对象,指的是进程/线程的,准确一点说是它的状态。
对于同步/异步,个人认为,与阻塞/非阻塞没有任何关系。它指的是如果当前方法想要得到一个最终的结果值,那么该方法就是同步的。同步意味着什么?每一条语句的执行都是依赖上一条一个确定的执行结果,整个执行过程是可以追踪,有迹可循的。而对于异步来说,当前语句并不关心返回的是否是最终结果,而一旦最终执行结果出来了,那么可以通过一种”信号“机制来告知当前进程。所以异步能够阻止进程的阻塞,从而进一步提高系统的响应速度。但是异步也有缺点,那就是如果要对代码执行进行追踪,则相对来说比较困难,因为并不清楚每一个异步操作的返回值是何时返回的。

参考文章:
简明网络I/O模型---同步异步阻塞非阻塞之惑

推荐阅读更多精彩内容