缓存服务器

PHP解决网站大数据大流量与高并发

与世无争的帅哥 提交于 2019-12-03 14:03:48
第一,硬件方面 普通的一个p4的服务器每天最多能支持大约10万左右的IP,如果访问量超过10W那么需要专用的服务器才能解决,如果硬件不给力 软件怎么优化都是于事无补的。主要影响服务器的速度 有:网络-硬盘读写速度-内存大小-cpu处理速度。 第二,软件方面 第一个要说的就是数据库,首先要有一个很好的架构,查询尽量不用* 避免相关子查询 给经常查询的添加索引 用排序来取代非顺序存取,如果条件允许 ,一般MySQL服务器最好安装 在Linux操作系统中 。关于apache和 nginx 在高并发的情况下推荐使用 nginx ,ginx是Apache服务器不错的替代品。nginx内存消耗少 官方测试能够支撑5万并发连接,在实际生产环境中跑 到2~3万并发连接数。 php 方面不需要的模块尽量关闭,使用memcached,Memcached 是一个高性能的分布式内存对象缓存系统,不使用数据库直接从内存当中调数据,这样大大提升了速 度,iiS或Apache启用GZIP压缩优化网站,压缩网站内容大大节省网站流量。 第二,禁止外部的盗链。 外部网站的图片或者文件盗链往往会带来大量的负载压力,因此应该严格限制外部对 于自身的图片或者文件盗链,好在目前可以简单地通过refer来控制盗链,Apache自 己就可以通过配置来禁止盗链,IIS也有一些第三方的ISAPI可以实现同样的功能。当 然

持久化存储与HTTP缓存

老子叫甜甜 提交于 2019-12-03 13:17:11
本文主要学习一下一些高级的HTTP知识,例如 Session LocalStorage Cache-Control Expires ETag 其实主要就是涉及到了 持久化存储与缓存的技术 在此之前已经学习了 Cookie 的 相关知识 ,但是 Cookie 有个缺点是可以人为修改,有一定的安全隐患。 所以,针对这个缺点,诞生了 Session Session 一般来说 Session 是基于Cookie实现的,它利用一个 sessionId 把用户的敏感数据隐藏起来,除非暴力穷举才有可能获得敏感数据。 sessionId 我们使用 Cookie 的时候,一般是服务器给用户一个响应头,设置 Cookie response.setHeader('Set-Cookie', 'sign_in_email=...;HTTPOnly') 既然Session还是基于 Cookie 实现的,那么还是应该在 Set-Cookie 上搞事情。 //预先在服务器端预留对象准备存储各种session let sessions = { } ... let sessionId = Math.random() * 100000 sessions[sessionId] = {sign_in_email: email} response.setHeader('Set-Cookie', `sessionId=$

死磕nginx系列--nginx 限流配置

a 夏天 提交于 2019-12-03 11:57:10
限流算法 令牌桶算法 算法思想是: 令牌以固定速率产生,并缓存到令牌桶中; 令牌桶放满时,多余的令牌被丢弃; 请求要消耗等比例的令牌才能被处理; 令牌不够时,请求被缓存。 漏桶算法 算法思想是: 水(请求)从上方倒入水桶,从水桶下方流出(被处理); 来不及流出的水存在水桶中(缓冲),以固定速率流出; 水桶满后水溢出(丢弃)。 这个算法的核心是:缓存请求、匀速处理、多余的请求直接丢弃。 相比漏桶算法,令牌桶算法不同之处在于它不但有一只“桶”,还有个队列,这个桶是用来存放令牌的,队列才是用来存放请求的。 从作用上来说,漏桶和令牌桶算法最明显的区别就是是否允许突发流量(burst)的处理,漏桶算法能够强行限制数据的实时传输(处理)速率,对突发流量不做额外处理;而令牌桶算法能够在限制数据的平均传输速率的同时允许某种程度的突发传输。 Nginx按请求速率限速模块使用的是漏桶算法,即能够强行保证请求的实时处理速度不会超过设置的阈值。 Nginx官方版本限制IP的连接和并发分别有两个模块: limit_req_zone 用来限制单位时间内的请求数,即速率限制,采用的漏桶算法 "leaky bucket"。 limit_req_conn 用来限制同一时间连接数,即并发限制。 limit_req_zone 参数配置 Syntax: limit_req zone=name [burst=number]

浏览器缓存的解决方案

夙愿已清 提交于 2019-12-03 10:52:48
浏览器缓存的解决方案 ——IT唐伯虎 摘要:浏览器缓存的解决方案,包括传统前端和现代前端。 前言:本文只针对文件请求(html、css、js)进行分析,但不涉及json数据请求。 浏览器的状态 (1)当浏览器向服务器发起请求,如果请求正常, 状态是200 。 (2)浏览器接收到请求结果后,如果会根据响应头设置的缓存规则,把请求结果存起来。 (3)当浏览器再次发起相同的请求的时候,浏览器会先向服务器比对文件,只对比最后修改时间,如果最后修改时间变化就重新获取请求结果,此时 状态是200 ;如果最后修改时间没有变化则从缓存读,此时 状态是304 。 (4)304状态是比较理想的缓存使用方案,但是往往来说,浏览器会走另一条粗暴的路线,即不进行时间比对,直接从缓存读,此时 状态是200已缓存 。 (200)> (304) > (200已缓存) (10ms)>(5ms)> (0ms) 浏览器的刷新 (1)按F5刷新: 从缓存读取文件,然后将这些文件向服务器对比,如果最后修改时间变化就重新下载,此时 状态是200 ,如果没变就从缓存读,此时 状态是304 ,这是只理想情况,有些时候,只从缓存读取, 状态是200已缓存 。 (2)按ctrl+F5强制刷新: 强制删除当前页面的所有缓存,并且重新下载,此时 状态是200 。 (3)手动清除浏览器所有缓存: 强制删除浏览器的所有缓存

App 后台架构

╄→гoц情女王★ 提交于 2019-12-03 10:37:25
转载请注明出处: http://blog.csdn.net/smartbetter/article/details/53933096 做App做的久了,就想研究一下与之相关的App后台,发现也是蛮有趣的。App后台的两个重要作用就是 远程存储数据 和 消息中转。这里面的知识体系也是相当复杂,做好一个App后台也是需要长期锤炼的。本篇文章从 App 后台架构 的角度介绍。好了,下面进入正题: 说起架构,我们先看一下何为架构,百度百科是这样说的:架构,又名软件架构,是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。那么我们也可以看出,架构是和业务紧密相关的,是由业务驱动的。 由于App客户端的特性,因此App后台对技术实现和一般的Web后台是有区别的。首先看一个适合App开发的开发模式: 1.敏捷开发模式 这里推荐Scrum这个敏捷开发框架,具体可以查看Scrum官网学习使用,这里只是引入。 Scrum流程如下图: 2.选择合适的数据库产品和服务器系统 数据库产品众多,这里我就针对Redis、MongoDB、MySQL还有MySQL的分支MariaDB展开说明: 1.数据库产品 数据库 数据存放位置 查找数据的区别 Redis 内存 基于键值对存储,读写速度快 MongoDB 同时使用了硬盘和内存 每个数据有一个id(索引),知道id(索引)查询速度快,不知道id

程序员需要了解的硬核知识之磁盘

亡梦爱人 提交于 2019-12-03 10:05:26
程序员需要了解的硬核知识之磁盘 https://www.cnblogs.com/cxuanBlog/p/11776310.html 此篇文章是 《程序员需要了解的硬核知识》系列第四篇,历史文章请戳 程序员需要了解的硬核知识之内存 程序员需要了解的硬核知识之CPU 程序员需要了解的硬核知识之二进制 我们大家知道,计算机的五大基础部件是 存储器 、 控制器 、 运算器 、 输入和输出设备 ,其中从存储功能的角度来看,可以把存储器分为 内存 和 磁盘 ,内存我们上面的文章已经介绍过了,那么此篇文章我们来介绍一下磁盘以及内存和磁盘的关系。 认识磁盘 首先,磁盘和内存都具有存储功能,它们都是存储设备。区别在于,内存是通过 电流 来实现存储;磁盘则是通过 磁记录技术 来实现存储。内存是一种高速,造假昂贵的存储设备;而磁盘则是速度较慢、造假低廉的存储设备;电脑断电后,内存中的数据会丢失,而磁盘中的数据可以长久保留。内存是属于 内部存储设备 ,硬盘是属于 外部存储设备 。一般在我们的计算机中,磁盘和内存是相互配合共同作业的。 一般内存指的就是主存(负责存储CPU中运行的程序和数据);早起的磁盘指的是软磁盘(soft disk,简称软盘),就是下面这个 (2000年的时候我曾经我姑姑家最早的计算机中见到过这个,当时还不知道这是啥,现在知道了。) 如今常用的磁盘是硬磁盘(hard disk,简称硬盘)

浏览器缓存和webpack缓存配置

梦想与她 提交于 2019-12-03 09:54:25
本文转载于: 猿2048 网站➞ https://www.mk2048.com/blog/blog.php?id=ia2jca2hcb 浏览器缓存 浏览器缓存分为两种类型: 强缓存 :也称为本地缓存,不向服务器发送请求,直接使用客户端本地缓存数据 协商缓存 :也称304缓存,向服务器发送请求,由服务器判断请求文件是否发生改变。如果未发生改变,则返回304状态码,通知客户端直接使用本地缓存;如果发生改变,则直接返回请求文件。 浏览器缓存机制的过程如下: 强缓存(本地缓存) 强缓存是最彻底的缓存,无需向服务器发送请求,通常用于css、js、图片等静态资源。浏览器发送请求后会先判断本地是否有缓存。如果无缓存,则直接向服务器发送请求;如果有缓存,则判断缓存是否命中强缓存,如果命中则直接使用本地缓存,如果没命中则向服务器发送请求。判断是否命中本地缓存的方法有两种: Expires 和 Cache-Control 。 Expires Expires是http1.0的响应头,代表的含义是资源本地缓存的过期时间,由服务器设定。服务器返回给浏览器的响应头中如果包含Expires字段,浏览器发送请求时拿当前时间和Expires字段值进行比较,判断资源缓存是否失效。如下图所示: Date 代表请求资源的时间, Expires 代表资源缓存的过期时间,可以看到服务器设置资源的缓存时间为5分钟。2017

Redis雪崩,击穿,穿透

ⅰ亾dé卋堺 提交于 2019-12-03 09:32:06
缓存雪崩:redis服务器挂掉导致请求大量涌至数据库;缓存穿透:大量缓存中不存在的请求key访问直接落到数据库,一般是恶意攻击;缓存击穿:热点key在请求高峰失效,瞬间大量请求落到数据库; 来源: https://www.cnblogs.com/znzuinb/p/11785536.html

[译] JavaScript 是如何工作的:Service Worker 的生命周期与使用场景

时光毁灭记忆、已成空白 提交于 2019-12-03 09:24:11
本文转载于: 猿2048 网站➞ https://www.mk2048.com/blog/blog.php?id=hkc1bh10jb 原文地址: How JavaScript works: Service Workers, their lifecycle and use cases 原文作者: Alexander Zlatkov 译文出自: 掘金翻译计划 本文永久链接: https://github.com/xitu/gold-miner/blob/master/TODO1/how-javascript-works-service-workers-their-life-cycle-and-use-cases.md 译者: talisk 校对者: allen , 赵立杨 这是专门探索 JavaScript 及其构建组件的系列的第八个。在识别和描述核心元素的过程中,我们也分享了一些我们在构建 SessionStack 时的最佳实践。SessionStack 是一个强大且性能卓越的 JavaScript 应用程序,可以向你实时显示用户在 Web 应用程序中遇到技术问题或用户体验问题时的具体情况。 如果你没看过之前的章节,你可以在这里看到: [译] JavaScript 是如何工作的:对引擎、运行时、调用堆栈的概述 [译] JavaScript 是如何工作的:在 V8 引擎里 5

MySQL查看数据库性能常用命令

你。 提交于 2019-12-03 09:15:43
一、查询服务器状态和配置 列出MySQL服务器运行各种状态值: mysql> show global status; 查询MySQL服务器配置信息语句: mysql> show variables; 二、慢查询 mysql> show variables like '%slow%'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | log_slow_queries | ON | | slow_launch_time | 2 | +------------------+-------+ mysql> show global status like '%slow%'; +---------------------+-------+ | Variable_name | Value | +---------------------+-------+ | Slow_launch_threads | 0 | | Slow_queries | 4148 | +---------------------+-------+  配置中打开了记录慢查询,执行时间超过2秒的即为慢查询,系统显示有4148个慢查询,你可以分析慢查询日志,找出有问题的SQL语句,慢查询时间不宜设置过长