缓存服务器

六、永无止境:网站的伸缩性架构

蹲街弑〆低调 提交于 2019-12-07 21:46:27
(1)网站架构的伸缩性设计 1.不同功能进行物理分离实现伸缩。纵向分离和横向分离,不同的服务器部署不同的业务。 2.单一功能通过集群规模实现伸缩。集群内的多台服务器部署相同的服务,提供相同的功能。 (2)应用服务器集群的伸缩性设计 如果HTTP请求分发装置可以感知或者可以配置集群的服务器数量,可以及时发现集群中新上线或下线的服务器,并能向新上线的服务器分发请求,停止向已下线的服务器分发请求,那么就实现了应用服务器集群的伸缩性。 这里,这个HTTP请求分发装置被称作均衡负载服务器。 实现负载均衡的技术,以下几种: 1.HTTP重定向负载均衡。 HTTP重定向服务器是一台普通的应用服务器,其唯一的功能就是根据用户的HTTP请求一台真实的Web服务器地址,并将该Web服务器地址写入HTTP重定向响应中(响应状态码为302)返回给用户浏览器。在图6.5中,浏览器请求访问域名 www.mysite.com 。DNS服务器解析得到IP地址是114.100.80.10,即HTTP重定向服务器的IP地址。然后浏览器通过IP地址 114.100.80.10访问HTTP重定向负载均衡服务器后,服务器根据某种负载均衡算法计算获得一台实际物理服务器的地址(114.100.80.3),构造一个包含该实际物理服务器地址的重定向响应返回给浏览器,浏览器自动重新请求实际物理服务器的IP地址(114.100.80

java web开发 高并发处理

假装没事ソ 提交于 2019-12-07 21:10:39
java处理高并发高负载类网站中数据库的设计方法(java教程,java处理大量数据,java高负载数据) 一:高并发高负载类网站关注点之数据库 没错,首先是数据库,这是大多数应用所面临的首个SPOF。尤其是Web2.0的应用,数据库的响应是首先要解决的。 一般来说MySQL是最常用的,可能最初是一个mysql主机,当数据增加到100万以上,那么,MySQL的效能急剧下降。常用的优化措施是M-S(主-从)方式进行同步复制,将查询和操作和分别在不同的服务器上进行操作。我推荐的是M-M-Slaves方式,2个主Mysql,多个Slaves,需要注意的是,虽然有2个Master,但是同时只有1个是Active,我们可以在一定时候切换。之所以用2个M,是保证M不会又成为系统的SPOF。 Slaves可以进一步负载均衡,可以结合LVS,从而将select操作适当的平衡到不同的slaves上。 以上架构可以抗衡到一定量的负载,但是随着用户进一步增加,你的用户表数据超过1千万,这时那个M变成了SPOF。你不能任意扩充Slaves,否则复制同步的开销将直线上升,怎么办?我的方法是表分区,从业务层面上进行分区。最简单的,以用户数据为例。根据一定的切分方式,比如id,切分到不同的数据库集群去。 全局数据库用于meta数据的查询。缺点是每次查询,会增加一次,比如你要查一个用户nightsailer

OkHttp:Java 平台上的新一代 HTTP 客户端

半世苍凉 提交于 2019-12-07 20:33:17
OkHttp 简介 OkHttp 库的设计和实现的首要目标是高效。这也是选择 OkHttp 的重要理由之一。OkHttp 提供了对最新的 HTTP 协议版本 HTTP/2 和 SPDY 的支持,这使得对同一个主机发出的所有请求都可以共享相同的套接字连接。如果 HTTP/2 和 SPDY 不可用,OkHttp 会使用连接池来复用连接以提高效率。OkHttp 提供了对 GZIP 的默认支持来降低传输内容的大小。OkHttp 也提供了对 HTTP 响应的缓存机制,可以避免不必要的网络请求。当网络出现问题时,OkHttp 会自动重试一个主机的多个 IP 地址。 在 Java 程序中使用 OkHttp 非常简单,只需要在 Maven 的 POM 文件中添加 代码清单 1 中的依赖即可。目前 OkHttp 的最新版本是 2.5.0。 清单 1. OkHttp 的 Maven 依赖声明 <!-- https://mvnrepository.com/artifact/com.squareup.okhttp/okhttp --> <dependency> <groupId>com.squareup.okhttp</groupId> <artifactId>okhttp</artifactId> <version>2.7.5</version> </dependency> HTTP 连接 虽然在使用

springboot集成redis

痞子三分冷 提交于 2019-12-07 18:02:22
springboot集成redis springboot集成redis 前言 1、maven导入依赖包 2、编写工具类-方便调用 3、在controller中调用 4、解决key值和value值乱码 前言 最近使用springboot做项目,使用了springboot+mybatis完成了一些基础接口的开发,其中有个接口,客户端大概需要每个10秒调用一次,每次调用都会连接一次数据库,然后查询,关闭连接,返回。大量频繁的连接数据库,增加了服务器性能的消耗,同时也使接口请求速度变慢。于是使用redis缓存来解决这一问题。 如果有redis不会安装的,可查看我之前的一篇博客,进行安装,地址 https://blog.csdn.net/u012489412/article/details/81218983 1、maven导入依赖包 springboot中要使用redis,先要导入相关的依赖包spring-boot-starter-data-redis,我这里使用maven进行导入。 <!-- redis缓存 --> < dependency > < groupId > org.springframework.boot </ groupId > < artifactId > spring-boot-starter-data-redis </ artifactId > </

Kafka——生产者发送原理分析

寵の児 提交于 2019-12-07 14:52:26
目录 整体架构 整体架构 整个生产过程由两个线程协调运行,分别为主线程和sender线程(发送线程)。在主线程中,由KafkaProducer创建消息,然后通过可能的拦截器、序列化器和分区器的作用之后,缓存消息到消息加载器(RecordAccumulator,也称为消息收集其)中,Sender线程负责从RecordAccumulator中获取消息并将其发送到Kafka中。 RecordAccumulator主要用来缓存消息以便Sender线程可以批量发送,进而减少网络传输的资源消耗以提升性能。RecordAccumulator缓存的大小可以通过生产者参数buffer.memory配置,默认值为33444432b,即32mb。如果生产者发送消息的速度大于发送到服务器的速度,也就是RecordAccumulator缓存不够,此时kafkaproducer的send方法调用要被被阻塞,要么抛出异常,这个取决于参数max.block.ms参数,此参数的默认值为60000ms,60s。 主线程发送过来的消息会被追加到RecordAccumulator的某个双端队列中,在RecordAccumulator内部为每个分区都维护了一个双端队列,队列中的内容就是ProducerBatch,即Deque 。消息写入缓存时,追加到双端队列的尾部,sender读取消息的时候,从双端队列的头部读取。注意

Web服务器及性能优化

半腔热情 提交于 2019-12-07 12:55:28
一、WEB服务器 1.1 概述: 1.2 区别: 1.2.1 Apache 1.2.2 Tomcat 1.2.3 Jboss 二、浏览器端,关于浏览器端优化 2.1 压缩源码和图片 2.2 选择合适的图片格式 2.3 合并静态资源 2.4 开启服务器端的Gzip压缩 2.5 使用CDN 2.6 延长静态资源缓存时间 2.7 把CSS放在页面头部,把JavaScript放在页面底部 三、服务端优化 3.1 HTML静态化 3.2 图片服务器分离 3.3 数据库集群、库表散列 3.4 缓存 3.5 镜像 3.6 负载均衡 3.6.1 硬件四层交换 3.6.2 软件四层交换 一、WEB服务器 1.1 概述: Apache是世界使用排名第一的Web服务器软件。它可以运行在几乎所有广泛使用的计算机平台上,由于其跨平台和安全性被广泛使用,是最流行的Web服务器端软件之一。 Apache与Tomcat都是Apache开源组织开发的用于处理HTTP服务的项目,两者都是免费的,都可以做为独立的Web服务器运行。 Apache是Web服务器而Tomcat是Java应用服务器。 1.2 区别: 1.2.1 Apache 是C语言实现的,专门用来提供HTTP服务。 特性:简单、速度快、性能稳定、可配置(代理) 1、主要用于解析静态文本,并发性能高,侧重于HTTP服务; 2、支持静态页(HTML)

草稿 -未整理

老子叫甜甜 提交于 2019-12-07 12:19:44
async和defer 1、defer="defer"和async="true/false" html4.0中定义了defer;html5.0中定义了async。 (1)没有defer或async,浏览器会立即加载并执行指定的JS脚本,也就是说,不等待后续载入的文档元素,读到JS脚本就加载并执行。 (2)有async,加载后续文档元素的过程将和JS的加载与执行并行进行(异步)。 (3)有defer,加载后续文档元素的过程将和JS的加载并行进行(异步),但JS的执行要在所有文档元素解析完成之后,DOMContentLoaded 事件触发之前完成。 2、defer和async的共同点: (1)不会阻塞文档元素的加载。 (2)使用这两个属性的脚本中不能调用document.write方法。 (3)允许不定义属性值,仅仅使用属性名。 (4)只适用于外部脚本(虽然IE4-IE7还支持对嵌入脚本的defer属性,但在IE8及之后的版本就只支持外部脚本,对不支持的会直接忽略defer属性,因此把延迟脚本放在页面底部仍然是最佳选择)。 3、defer和async的不同点: (1)每一个async属性的脚本一旦加载完毕就会立刻执行,一定会在window.onload之前执行,但可能在document的DOMContentLoaded之前或之后执行。不保证按照指定它们的顺序来执行

HTTP Request Response详讲

被刻印的时光 ゝ 提交于 2019-12-07 10:50:20
HTTP Request header 当今web程序的开发技术真是百家争鸣,ASP.NET, PHP, JSP,Perl, AJAX 等等。 无论Web技术在未来如何发展,理解Web程序之间通信的基本协议相当重要, 因为它让我们理解了Web应用程序的内部工作. 本文将对HTTP协议进行详细的实例讲解,内容较多,希望大家耐心看。也希望对大家的开发工作或者测试工作有所帮助。使用Fiddler工具非常方便地捕获HTTP Request和HTTP Response, 关于Fiddler工具的用法,请看我另一篇博客[ Fiddler 教程 ] 阅读目录 什么是HTTP协议 协议是指计算机通信网络中两台计算机之间进行通信所必须共同遵守的规定或规则,超文本传输协议(HTTP)是一种通信协议,它允许将超文本标记语言(HTML)文档从Web服务器传送到客户端的浏览器 目前我们使用的是HTTP/1.1 版本 Web服务器,浏览器,代理服务器 当我们打开浏览器,在地址栏中输入URL,然后我们就看到了网页。 原理是怎样的呢? 实际上我们输入URL后,我们的浏览器给Web服务器发送了一个Request, Web服务器接到Request后进行处理,生成相应的Response,然后发送给浏览器, 浏览器解析Response中的HTML,这样我们就看到了网页,过程如下图所示 我们的Request

PHP如何解决网站大流量与高并发

北城以北 提交于 2019-12-07 09:41:27
首先,确认服务器硬件是否足够支持当前的流量。 普通的P4服务器一般最多能支持每天10万独立IP,如果访问量比这个还要大, 那么必须首先配置一台更高性能的专用服务器才能解决问题 ,否则怎么优化都不可能彻底解决性能问题。 其次,优化数据库访问。 前台实现完全的静态化当然最好,可以完全不用访问数据库,不过对于频繁更新的网站, 静态化往往不能满足某些功能。 缓存技术就是另一个解决方案,就是将动态数据存储到缓存文件中,动态网页直接调用这些文件,而不必再访问数据库,WordPress和Z-Blog都大量使用这种缓存技术。 如果确实无法避免对数据库的访问,那么可以尝试优化数据库的查询SQL.避免使用 Select * from这样的语句,每次查询只返回自己需要的结果,避免短时间内的大量SQL查询。 第三,禁止外部的盗链。 外部网站的图片或者文件盗链往往会带来大量的负载压力,因此应该严格限制外部对于自身的图片或者文件盗链,好在目前可以简单地通过refer来控制盗链,Apache自己就可以通过配置来禁止盗链,IIS也有一些第三方的ISAPI可以实现同样的功能。当然,伪造refer也可以通过代码来实现盗链,不过目前蓄意伪造refer盗链的还不多,可以先不去考虑,或者使用非技术手段来解决,比如在图片上增加水印。 第四,控制大文件的下载。 大文件的下载会占用很大的流量,并且对于非SCSI硬盘来说

Android 异步加载图片,使用LruCache和SD卡或手机缓存,效果非常的流畅

我与影子孤独终老i 提交于 2019-12-07 03:22:06
转载请注明出处 http://blog.csdn.net/xiaanming/article/details/9825113 异步加载图片的例子,网上也比较多,大部分用了HashMap<String, SoftReference<Drawable>> imageCache ,但是现在已经不再推荐使用这种方式了,因为从 Android 2.3 (API Level 9)开始,垃圾回收器会更倾向于回收持有软引用或弱引用的对象,这让软引用和弱引用变得不再可靠。另外,Android 3.0 (API Level 11)中,图片的数据会存储在本地的内存当中,因而无法用一种可预见的方式将其释放,这就有潜在的风险造成应用程序的内存溢出并崩溃,所以我这里用得是LruCache来缓存图片,当存储Image的大小大于LruCache设定的值,系统自动释放内存,这个类是3.1版本中提供的,如果你是在更早的Android版本中开发,则需要导入android-support-v4的jar包(这里要注意咯) 为什么写这篇文章呢? 因为我之前做的项目中,也有异步加载图片,那时候用得是Thread去下载图片,每次下载图片都要new Thread去下载,而且还是并发去下载,每次都new 一个线程浪费内存,老板说服务器承受不起这么多的连接,叫我改成先获取一张图片之后再去获取下一张,这样子保存与服务器的连接为一个