设为首页 加入收藏

TOP

大型网站系统与 Java 中间件实践(一)
2017-12-30 06:06:51 】 浏览:98
Tags:大型 网站 系统 Java 中间件 实践

第一章 分布式系统介绍

分布式系统的定义:组件分布在网络计算机上,组件间仅仅通过消息传递来通信并协调行动。

分布式系统的意义:

  • 升级单机处理能力的性价比越来越低
  • 单机处理能力存在瓶颈
  • 处于稳定性和可用性的考虑

摩尔定律:当价格不变时,每隔18个月,集成电路上可容纳的晶体管数目会增加一倍,性能也将提升一倍。

线程与进程的执行模式

冯诺依曼结构:输入设备、输入设备、运算器、控制器、存储器。

基于共享容器协同的多线程模式:经典如生产者消费者问题,对于存储数据的容器或对象,有线程安全和不安全之分,对于不安全的容器或对象,一般可以通过加锁或者通过Copy On Write的方式控制并发。

通过事件协同的多线程模式:避免死锁

多进程模式:

  • 线程是属于进程的,一个进程内的多个线程共享了进程的内存空间;而多个进程间的内存空间是独立的,因此多个进程间通过内存共享、交换数据的方式与多个线程间就有所不同
  • 此外,进程间通信、协调,以及通过一些事件通知或者等待一些互斥锁的释放方面也不一样
  • 多进程相对于单进程多线程来说,资源控制会更容易实现;多进程中单个进程出现问题,不会造成整体的不可用
  • 多进程之间可以共享数据,但其代价较大,会涉及序列化和反序列化的开销

网络通信基础知识

OSI七层模型与TCP/IP模型:

Socket套接字进行网络通信开发时,用到的三种方式:BIO、NIO和AIO

BIO:Blocking IO,采用阻塞的方式实现,一个线程处理一个Socket,发生建立连接、读数据、写数据的操作时,都可能会阻塞。

NIO:Nonblocking IO,基于时间驱动思想,采用Reactor模式,可以在一个线程中处理多个Socket套接字

AIO:AsynchronousIO,异步IO,采用Proactor模式,与NIO的差别是,AIO在进行读写操作时,只需要调用响应的read/write方法,并且需要传入CompletionHandler,在动作完成后会调用。

如何把应用从单机扩展到分布式

输入设备的变化

输出设备的变化

控制器的变化

方式1和2,透明代理:对发起方和处理方都是透明的

  • 使用硬件负载均衡
  • 使用LVS(或其他软件负载均衡系统)

缺点:

  • 会增加网络的开销,一方面指流量,另一方面指延迟
  • 这个透明代理处于请求的必经之路,如果代理出现问题,所有请求都会受到影响。我们需要考虑代理服务器的热备份

方式3,采用名称服务器直连的方式:

请求发起方和处理方直接没有代理服务器,而是直接连接。外部多了一个“名称服务”的角色,作用有:

  • 收集提供请求处理的服务器的地址信息
  • 提供这些地址信息给请求发起方

名称服务只是起到一个地址交换的作用,在发起请求的机器上,需要根据从名称服务得到的地址进行负载均衡的工作。

优点如下:

  • 名称服务器出现问题,有办法可以保证处理正常
  • 发起方和处理方直连,减少中间路径和带宽小号

缺点就是代码升级较复杂

方式4,采用规则服务器控制路由的请求直连调用

与名称服务器不同的是,规则服务器并不和请求处理的机器交互,只负责把规则提供给请求发起的机器。

方式5,Master+Worker的方式

存在一个Master节点来管理任务,由Master把任务分配给不同的Worker进行处理。

运算器的变化

  • 通过DNS服务器进行调度和控制
  • 增加负载均衡设备,DNS返回的永远是负载均衡地址

存储器的变化

同控制器的变化,加代理服务器、or名称服务器、or规则服务器

分布式系统的难点

  • 缺乏全局时钟
  • 面对故障独立性
  • 处理单点故障,如果不能把单点变为集群,则需要给单点做好备份,降低单点故障影响范围
  • 事务的挑战:2PC、最终一致、BASE、CAP、Paxos等

第二章 大型网站及其架构演进过程

大型网站:访问量(PV)、数据量、业务复杂度

单机负载告警,数据库与应用分离

应用服务器负载告警,走向集群

  • 服务器选择问题:DNS、集群前加负载均衡设备
  • Session的问题

Session保存会话状态,在Web服务器上,各个会话独立存储,多台服务器不能保证每次请求都落在同一边的服务器上。解决方案如下:

1、Session Sticky:负载均衡根据会话标识进行转发,让同样的Session请求每次都发送到同一个服务器端处理

缺点:

  • 如果一台Web服务器宕机或重启,会话数据会丢失,用户要重新登录
  • 会话标识是应用层信息,则负载均衡要在应用层进行解析,开销比在第四层大
  • 负载均衡变为了有状态的节点,要将会话保存到具体Web服务器的映射。内存消耗会变大,容灾更麻烦

2、Session Replication:会话在多态服务器上复制同步

缺点:

  • 同步Session数据造成了网络带宽的开销
  • 每台Web服务器都要保存所有的Session数据,数据量容易很大

3、Session数据集中存储

Session数据不再Web服务器上,而是放在另一个集中存储的地方。

缺点:

  • 读写Session数据引入了网络操作,存在时延和不稳定性
  • 如果集中存储Session的机器或者集群有问题,就会影响我们的应用

4、Cookie Based:把Session数据放在Cookie中

缺点:

  • Cookie长度的限制
  • 安全性:外部访问和修改
  • 带宽消耗
  • 性能影响:每次HTTP请求都带有Session数据

数据读压力变大,读写分离

1、采用数据库作为读库

缺点:

  • 数据复制问题;
  • 应用对于数据源的选择问题:写操作和事务走主库,考虑从库相对主库的延迟

2、搜索引擎其实是一个读库

3、加速数据读取的利器——缓存

  • 数据缓存,Key-Value,“热数据”,容量不够时清除缓存
  • 页面缓存,ESI标签页面缓存

弥补关系型数据库的不足,引入分布式存储系统

分布式文件系统,解决小文件和大文件的存储问题
分布式key-value系统,提供高性能的半结构化支持
分布式数据库提供一个支持大数据、高并发的数据库系统

读写分离后,数据库又遇到瓶颈

尽管读写分离以及分布式存储系统,能够降低主库的压力,但是交易、商品、用户的数据都还在一个数据库中,压力还在继续增加,我们有数据垂直拆分和水平拆分两种选择;

1、专库专用,数据垂直拆分

垂直拆分即把不同的业务数据分到不同的数据库中。

问题:

  • 应用需要多个数据源,带来的是每个数据库连接池的隔离
  • 单机跨业务事务,一种方法是使用分布式事务,性能较低;另一种办法就是去掉事务

2、单表达到瓶颈,数据水平拆分

水平拆分就是把同一个表的数据拆到两个数据库中。

问题:

  • SQL路由问题,选择哪个数据表
  • 主键处理等机制不同,如自增主键
  • 一些查询需要从两个数据库中取数据,加上分页操作,比较难处理

数据库问题解决后,应用面对的新挑战

拆分应用

  • 根据业务特性,还可以根据用户注册、登陆、用户信息维护等再拆分。
  • 走服务化的路,共享代码放在各个服务中心,如商品中心、用户中心、交易中心

初识消息中间件

消息中间件是在分布式系统中完成消息发送和接收的基础软件。两个明显好处:异步、解耦。

第三章 构建Java中间件

三个领域的中间件:

  • 远程过程调用和对象访问中间件:主要解决分布式环境下应用的互相访问问题。是支撑应用服务化的基础

  • 编程开发网
首页 上一页 1 2 3 下一页 尾页 1/3/3
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
上一篇IDEA 代码生成插件 CodeMaker 下一篇String 常量池和 String#intern()

评论

帐  号: 密码: (新用户注册)
验 证 码:
表  情:
内  容:

最新文章

热门文章

C 语言

C++基础

windows编程基础

linux编程基础

C/C++面试题目