缓存服务器

只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性问题？ 面试题剖析 一般来说，如果允许缓存可以稍微的跟数据库偶尔有不一致的情况，也就是说如果你的系统不是严格要求 “缓存+数据库” 必须保持一致性的话，最好不要做这个方案，即：读请求和写请求串行化，串到一个内存队列里去。 串行化可以保证一定不会出现不一致的情况，但是它也会导致系统的吞吐量大幅度降低，用比正常情况下多几倍的机器去支撑线上请求。 Cache Aside Pattern 最经典的缓存+数据库读写的模式，就是 Cache Aside Pattern。 读的时候，先读缓存，缓存没有的话，就读数据库，然后取出数据后放入缓存，同时返回响应。 更新的时候，先更新数据库，然后再删除缓存。 为什么是删除缓存，而不是更新缓存？ 原因很简单，很多时候，在复杂点的缓存场景，缓存不单单是数据库中直接取出来的值。 比如可能更新了某个表的一个字段，然后其对应的缓存，是需要查询另外两个表的数据并进行运算，才能计算出缓存最新的值的。 另外更新缓存的代价有时候是很高的。是不是说，每次修改数据库的时候，都一定要将其对应的缓存更新一份？也许有的场景是这样，但是对于比较复杂的缓存数据计算的场景，就不是这样了。如果你频繁修改一个缓存涉及的多个表，缓存也频繁更新。但是问题在于

简洁版： [client] port = 3306 socket = /weyeedata/mysql/run/mysql.sock [mysqld] innodb_buffer_pool_size = 512M #log_bin = 1 expire_logs_days = 7 basedir = /usr/local/mysql datadir = /weyeedata/mysql/data port = 3306 bind = 0.0.0.0 server_id = 1 socket = /weyeedata/mysql/run/mysql.sock innodb_file_per_table = 1 skip_name_resolve = 1 #binlog_format = row log_error = /weyeedata/mysql/logs/mysql-error.log slow_query_log = 1 long_query_time = 1 slow_query_log_file = /weyeedata/mysql/logs/mysql-slow.log join_buffer_size = 128M sort_buffer_size = 2M read_rnd_buffer_size = 2M max_connections = 10000 sql

你知道的越多，你不知道的越多 点赞再看，养成习惯 GitHub 上已经开源 https://github.com/Java… ，有面试点思维导图，欢迎 Star 和 完善 前言 Redis 在互联网技术存储方面使用如此广泛，几乎所有的后端技术面试官都要在 Redis 的使用和原理方面对小伙伴们进行360°的刁难。 作为一个在互联网公司面一次拿一次Offer的面霸，打败了无数竞争对手，每次都只能看到无数落寞的身影失望的离开，略感愧疚（ 请允许我使用一下夸张的修辞手法 ）。 于是在一个寂寞难耐的夜晚，我痛定思痛，决定开始写 《吊打面试官》 系列，希望能帮助各位读者以后面试势如破竹，对面试官进行360°的反击，吊打问你的面试官，让一同面试的同僚瞠目结舌，疯狂收割大厂Offer！ 絮叨 上一期因为是在双十一一直在熬夜的大环境下完成的，所以我自己觉得质量明显没之前的好，我这不一睡好就加班加点准备补偿大家，来点干货。（熬夜太容易感冒了，这次 点个赞 别白嫖了！） 顺带提一嘴，我把我准备写啥画了一个思维导图，以后总不能每篇都放个贼大的图吧，就开源到了我的 GitHub ，大家有兴趣可以去完善和 Star 。 这篇我就先放出来大家看看，感觉还是差点意思，等大家完善了。 回望过去 上一期吊打系列我们提到了 Redis 相关的一些知识，还没看的小伙伴可以回顾一下 《吊打面试官》系列-Redis基础

Redis缓存 @[toc] 简介 redis是一个高性能的key-value数据库 优势 性能强，适合高度的读写操作（读的速度是110000次/s,写的速度是81000次/s ）。 支持较为丰富的数据类型（如二进制的Strings, Lists, Hashes, Sets ,Ordered Sets） 一定的事物能力（要么执行成功要么完全不执行）。 劣势 内存数据库访问快，但也消耗硬件内存资源 注：redis的单线程仅仅是说在网络请求这一模块上用一个请求处理客户端的请求，但比如说持久化它就会重开一个线程/进程去进行处理。 引入redis缓存 点击链接 下载 redis 的 window 版，下载好后，放入你平时放软件的位置，解压出来即安装完成。（需要注意的是放入的文件目录，当前用户要是可读可写的权限，比如window下的C:\Program Files (x86)，这个目录默认只有管理员权限才能读写，redis运行时要在该目录下实时写入日志文件的，若无权限读写，则会操作不成功） 解压出来的目录如下所示，因为是Windows端的，可双击exe文件开启客户端，服务端。 因为这是 springboot 整合 redis 系列，所以双击打开服务端即可，别关闭打开的 cmd 窗口。 在pom.xml中加入 <dependency> <groupId>org.springframework

原文链接： http://www.cnblogs.com/thatsit/p/ci-panio-xing-neng-you-huashi-jian.html RAID卡缓存策略调整 原因详解 操作实例 I/O 调度算法 文件系统journal 磁盘挂载参数 操作实例 性能数据对比 RAID卡缓存策略调整 可以将RAID卡缓存策略由 No Write Cache if bad BBU 调整为 Write Cache OK if bad BBU ，即在电池充放电时不关闭缓存，以此保证I/O性能。但是此法存在数据丢失风险，需要合理评估再做调整。 原因详解 　　服务器的Riad卡都带有可充电电池，这块可充电电池在不使用时也会有微弱的放电现象，当它的电量放电到低到一定程度时，Raid卡控制器就会对电池进行一次“放电”，将剩余的电量放掉，然后再进行一次“充电”。这其实是一种对电池保护机制，以及对Raid卡可用性提供保障的机制。 　　默认情况下，当RAID卡的电池的电量低于某阈值时，RAID卡固件认为此时的电池是不可用的，为了保证数据的安全，会禁用RAID的“缓存”，这种默认的机制本来是合理的，但是当RAID的缓存被禁用之后，RAID的I/O能力会大幅度下降。一般情况下，这个充放电(放电->充电)的时间可能会持续几个小时，对于I/O密集型的应用来说，由此带来的性能下降有可能是致命的

大白话布隆过滤器 https://www.cnblogs.com/CodeBear/p/10911177.html 本文是站在小白的角度去讨论布隆过滤器，如果你是科班出身，或者比较聪明，又或者真正想完全搞懂布隆过滤器的可以移步。 不知道从什么时候开始，本来默默无闻的布隆过滤器一下子名声大燥，仿佛身在互联网，做着开发的，无人不知，无人不晓，哪怕对技术不是很关心的小伙伴也听过它的名号。我也花了不少时间去研究布隆过滤器，看了不少博客，无奈不是科班出身，又没有那么聪明的头脑，又比较懒...经过“放弃，拿起，放弃，拿起”的无限轮回，应该算是了解了布隆过滤器的核心思想，所以想给大家分享下。 布隆过滤器的应用 我们先来看下布隆过滤器的应用场景，让大家知道神奇的布隆过滤器到底能做什么。 缓存穿透 我们经常会把一部分数据放在Redis等缓存，比如产品详情。这样有查询请求进来，我们可以根据产品Id直接去缓存中取数据，而不用读取数据库，这是提升性能最简单，最普遍，也是最有效的做法。一般的查询请求流程是这样的：先查缓存，有缓存的话直接返回，如果缓存中没有，再去数据库查询，然后再把数据库取出来的数据放入缓存，一切看起来很美好。但是如果现在有大量请求进来，而且都在请求一个不存在的产品Id，会发生什么？既然产品Id都不存在，那么肯定没有缓存，没有缓存，那么大量的请求都怼到数据库，数据库的压力一下子就上来了

一、redis来源 二、数据类型 三、主流的应用场景 四、特性 五、补充 一、 redis来源 redis作者：Salvatore Sanfilippo （antirez），男，意大利人. 需求：一个访客信息追踪网站，网站可以通过JavaScript脚本，将访客的IP地址、所属国家、阅览器信息、被访问页面的地址等数据传送给LLOOGG. com。然后LLOOGG.com会将这些浏览数据通过web页面实时地展示给用户，并储存起最新的5至10,000条浏览记录以便进行查阅。 redis解决方案 每当某个被追踪的网站新增一条浏览记录时，LLOOGG.com就会将这条新的浏览记录推入（push）到与该网站相对应的列表里面，当列表的长度超过用户指定的最大长度时，程序每向列表推入一条新的记录，就需要从列表中弹出（pop）一条最旧的记录。 现在已经被广泛使用： Twitter使用Redis来储存用户时间线（user timeline）。 StackOverflow使用Redis来进行缓存和消息分发。 Pinterest使用Redis来构建关注模型（follow model）和兴趣图谱（interest graph）。 Flickr使用Redis来构建队列。 Github使用Redis作为持久化的键值对数据库，并使用Resque来实现消息队列。 新浪微博使用Redis来实现计数器、反向索引、排行榜

当我们输入 URL 并按回车后，浏览器会对 URL 进行检查，首先判断URL格式，比如是ftp http ed2k等等，我们这里假设这个URL是 http://hellocassie.cn ，那么浏览器会对这个 URL 进行安全检查，然后浏览器内核会先查看缓存，再决定是发起请求，下载页面，还是从缓存获取页面，如果是第一次访问，这时候还没有缓存，所以会去向服务器发起一个网络请求。 下载页面 首先我们要确定服务器的网络地址，才能把请求发给它，所以要把这个URL转换成对应的IP地址，浏览器会依次从浏览器缓存，系统缓存，路由器缓存，本地DNS服务器进行一个递归查询，如果本地DNS服务器也没有对应的IP地址的记录，这时候它会把请求发至13台根域名服务器，根域名服务器收到请求后会判断这个域名是谁来授权管理，然后返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，再去联系顶级域名服务器。顶级域名服务器收到请求后，如果自己无法解析，再返回下一级域名服务器的IP，进行这样一个迭代查询之后，一直到子域名服务器。 这个时候有两种情况，第一种是子域名服务器返回了这个URL对应的IP地址，第二种情况是经过了CDN调度，如果目标网站使用了CDN服务，则需要在CDN服务商的平台设置相应的CNAME记录，这个记录是CDN服务厂商的一个DNS服务器的域名，子域名服务器会返回这个CNAME记录

在进行性能测试之前，需要跟开发问清楚性能测试的目的，是为了找到系统能支撑的最大负载还是为了检查在一定负载下系统的运行情况。如果是后者的话，还需要问一下服务器端设置的最大并发线程数，这样测试时才能设置出合适的负载量。我之前做过的几次http请求的压测，都是为了找系统能支持的最大负载。本次压测，我先在本地测试，给了50个线程并循环100次，结果在测试运行一段时间后就会出现需要等待很长时间的情况，一开始以为是本地网络状况不佳，将脚本放在服务器上跑依然会出现这个情况，后来跟开发沟通知道服务端设置了最大并发量的限制，并且只需要测试一下特定线程下系统的性能情况即可。有了这次经验之后，在之后的性能测试前就知道要尽量问清楚测试需求了。 还有一点需要注意的是缓存对于性能的影响，有无缓存对性能的影响通常是很大的，需要跟开发确认好重点关注的是有缓存还时没有缓存的情况。本次压测，有一个测试类是查询文章subject（话题）属性的，话题属性是实时计算出来的，如果传入的docid是第一次调用该方法，返回话题属性耗时会比较长，之后再对同一个docid查询话题属性时是直接从缓存中取数据返回，耗时大大减少。对获取话题属性的方法进行性能测试，在40个线程、重复100次的压力下，没有缓存和有缓存时的TPS分别为70/s和2200/s，可见两种情况下的差距之大。 一般性能测试的时候还需要关注其他的一些信息

你知道的越多，你不知道的越多 点赞再看，养成习惯 前言 Redis 在互联网技术存储方面使用如此广泛，几乎所有的后端技术面试官都要在 Redis 的使用和原理方面对小伙伴们进行360°的刁难。作为一个在互联网公司面一次拿一次offer的面霸（ 请允许我使用一下夸张的修辞手法 ），打败了无数竞争对手，每次都只能看到无数落寞的身影失望的离开，略感愧疚，在一个寂寞难耐的夜晚，我痛定思痛，决定开始写 《吊打面试官》 系列，希望能帮助各位读者以后面试势如破竹，对面试官进行360°的反击，吊打问你的面试官，让一同面试的同僚瞠目结舌，疯狂收割大厂offer！ 絮叨 男儿何不带吴钩，收取关山五十州 FPX 🐂B，LPL两年连冠🏆 🐂B！ 看着金色的雨落下，我到窗边，发现天有点蓝，风有点绵，我的眼角又湿了! 最近双十一讲道理有点忙的说，直接肝爆，就是这样作为 暖男 的我，还是给你们挤出时间搞出终章，忍不住给自己 点赞 👍 放个双十一照片证明真的忙，希望别取关！！！ 现在你们在看的时候，我应该还在睡觉哈哈。困🛌 之前跟你们说的， 限流 ， 降级 ，是不是在双十一又应验了，下单接口其实没挂，牺牲部分用户体验，保住服务器，你多点几下是可以成功的，等流量高峰过去了，所有的用户全部都恢复正常访问，服务器也没啥事。 去年退款接口被打崩了，今年阿里明显也聪明了很多。 正文