HTTP1.0和HTTP1.1的一些区别
HTTPS与HTTP的一些区别
HTTP2.0和HTTP1.X相比的新特性
容灾分为两大类:
异地容灾系统有本地数据的一个副本,数据可以是本地生产数据的实时复制,也可以比本地数据稍微落后。如配置mysql数据库主从热备份。
在数据级容灾基础上,在异地建立一套与本地生产系统相当的备份环境,包括主机、网络、应用、IP等资源均有配套,当本地系统发生灾难时,异地系统可以提供完全可用的生产环境。
比较流行的集中容灾解决方案有:
一对一备灾
两地三中心
多对一统一备灾
现代备灾方式
参考:https://wenku.baidu.com/view/40b46c7b7f1922791788e854.html
异地双活(多机房部署)
异地多活的好处包括异地灾备、提升(南方电信)用户访问速度、提升海外用户访问速度、降低部署成本(如:北京机房机架费太贵了)等。通过实践发现优势包括异地容灾、动态加速、流量均衡、在线压测等,而挑战包括增加研发复杂度、存储成本增加等。
异地多活面临的挑战
机房之间的延时:微博北京的两个核心机房间延时在1ms左右,但北京机房到广州机房则有近40ms的延时。对比一下,微博核心Feed接口的总平均耗时也就在120ms左右。微博Feed会依赖几十个服务上百个资源,如果都跨机房请求,性能将会惨不忍睹;
专线问题:为了做广州机房外部,微博租了两条北京到广州的专线,成本巨大。同时单条专线的稳定性也很难保障,基本上每个月都会有或大或小的问题;
数据同步问题:MySQL如何做数据同步?HBase如何做数据同步?还有各种自研的组件,这些统统要做多机房数据同步。几十毫秒的延时,加上路途遥远导致的较弱网络质量(我们的专线每个月都会有或大或小的问题),数据同步是非常大的挑战;
依赖服务部署问题:如同阿里目前只做了交易单元的“异地双活”,微博部署时也面临核心服务过多依赖小服务的问题。将小服务全部部署改造成本、维护成本过大,不部署则会遇到之前提到的机房之间延时导致整体性能无法接受的问题;
配套体系问题:只是服务部署没有流量引入就不能称为“双活”,而要引入流量就要求配套的服务和流程都能支持异地部署,包括预览、发布、测试、监控、降级等都要进行相应改造;
方案选型时需要考虑的一些维度:
能否整业务迁移:如果机器资源不足,建议优先将一些体系独立的服务整体迁移,这样可以为核心服务节省出大量的机架资源。如果这样之后,机架资源仍然不足,再做异地多活部署;
服务关联是否复杂:如果服务关联比较简单,则单元化、基于跨机房消息同步的解决方案都可以采用。不管哪种方式,关联的服务也都要做异地多活部署,以确保各个机房对关联业务的请求都落在本机房内;
是否方便对用户分区:比如很多游戏类、邮箱类服务由于用户可以很方便分区就非常适合单元化,而SNS类的产品因为关系公用等问题不太适合单元化;
谨慎挑选第二机房:尽量挑选离主机房较近(网络延时在10ms以内)且专线质量好的机房做第二中心。这样大多数的小服务依赖问题都可以简化掉,可以集中精力处理核心业务的异地双活问题。同时,专线的成本占比也比较小。以北京为例,做异地多活建议选择天津、内蒙古、山西等地的机房;
控制部署规模:在数据层自身支持跨机房服务之前,不建议部署超过两个的机房。因为异地两个机房,异地容灾的目的已经达成,且服务器规模足够大各种配套的设施也会比较健全,运维成本也相对可控。当扩展到三个点之后,新机房基础设施磨合、运维决策的成本等都会大幅增加;
消息同步服务化:建议扩展各自的消息服务,从中间件或者服务层面直接支持跨机房消息同步,将消息体大小控制在10k以下,跨机房消息同步的性能和成本都比较可控。机房间的数据一致性只通过消息同步服务解决,机房内部解决缓存等与消息的一致性问题。跨机房消息同步的核心点在于消息不能丢,微博由于使用的是MCQ,通过本地写远程读的方式,可以很方便的实现高效稳定的跨机房消息同步;
Timewait的作用:
1.我们都知道的是time_wait太短或者取消,可能会使上一个连接延迟的数据包(关闭连接,但是没有关闭完全),所以延迟的数据包可能被新的连接收到,从而影响到新连接的数据。
2.第二个作用是采用正常的time_wait机制会防止最后一个对FIN的ACK丢失
TIME_WAIT存在的两个理由:
1 可靠的实现TCP全双工连接的终止
2 允许老的重复的分节在网络上的消逝
解决服务器连接状态TIME_WAIT过多问题:
1、开启apache的keepalive选项
2、有关内核级别的keepalive和time_await的优化调整
其它解决方法
1)可以改为长连接,但代价较大,长连接太多会导致服务器性能问题,而且PHP等脚本语言,需要通过proxy之类的软件才能实现长连接;
2)修改ipv4.ip_local_port_range,增大可用端口范围,但只能缓解问题,不能根本解决问题;
3)客户端程序中设置socket的SO_LINGER选项;
4)客户端机器打开tcp_tw_recycle和tcp_timestamps选项;
5)客户端机器打开tcp_tw_reuse和tcp_timestamps选项;
6)客户端机器设置tcp_max_tw_buckets为一个很小的值;