Redis的n种妙用,不仅仅是缓存
Redis的n种妙用,不仅仅是缓存。
Redis的n种妙用,不仅仅是缓存
Redis的n种妙用,不仅仅是缓存。
Redis的n种妙用,不仅仅是缓存
如何用普通设备实现海量数据的毫秒级查询?文章分享了在 ThinkPad 上构建 Redis 系统的完整方案,详细解析了数据分片、查询优化和资源调配等关键技术,还提供了针对高效查询的实际案例。轻量化实现,高性能表现,为开发者提供了实用的参考思路,值得深入学习!
Redis中为了实现高可用(High Availability,简称HA),采用了如下两个方式:
1、主从复制数据。
2、采用哨兵监控数据节点的运行情况,一旦主节点出现问题由从节点顶上继续进行服务。
不论面试还是实际工作中,Redis都是避无可避的技术点。在我心里,MySQL和Redis是衡量一个程序员是否“小有所成”的两把标尺。如果他能熟练使用MySQL和Redis,以小化大,充分利用现有资源出色地完成当下需求,说明他已经成长了。
本篇文章我们一起来探讨Redis分布式锁相关的内容。
说到锁,大家第一时间想到的应该是synchronized关键字或ReentrantLock,随即想到偏向锁、自旋锁、重量级锁或者CAS甚至AQS。一般来说,我不喜欢一下子引入这么多概念,可能会把问题弄复杂,但为了方便大家理解Redis分布式锁,这里稍微提一下。
最近发现无论改多少内容,打包出来的所有文件的 hash 都会发生变化,这样就导致了浏览器缓存失效,每次都要重新加载所有文件,这样就导致了加载速度变慢,而且也浪费我服务器流量,姑且来看看能不能解决。
在上一篇文章: Redis 核心数据结构(1) 中,介绍了链表、ziplist、quicklist 数据结构。这篇文章,来介绍一下 skiplist、dict。
skiplist 跳跃表是一种有序数据结构,支持平均 O(logN)、最坏 O(N) 复杂度的节点查找;大部分情况效率可以和平衡树相媲美,实现却比平衡树简单。
跳跃表就是 Redis 中有序集合键的底层实现之一。
Redis 目前是使用最广泛的缓存中间件。其突出特点就是支持多种常见的数据结构。对比 JDK 集合类的实现,Redis 的实现表现出很多独到之处,很多地方设计得别具匠心。下面就来简要介绍一下。
昨天在测试一个 Android APK 的时候发现使用 WiFi 的 HTTP 代理无法抓到包,在代理的日志中没有发现任何 SSL Alert,因此可以判断不是证书问题;另外 APP 本身仍可以正常收发数据,这说明代理设置被应用绕过了。
根据我们前一篇文章(终端应用安全之网络流量分析)中所介绍的,遇到这种情况时就可以使用路由抓包方法,确保接管所有流量。但是因为端午放假被封印在家,且用于抓包的树莓派放在了公司,因此只有另谋他路。
本来接着考虑装个 DroidProxy 去试一下,但突然间灵光一闪,为什么不直接用 iptables 去修改流量呢?于是,就有了这篇小记。
之前我们遇到过热key,命中了集群中的一组服务器,导致其网卡PPS超出了极限值,经常性出现redis响应变慢的问题。
我们随即对机器和网卡进行了升级,升级成多队列网卡,设置了4个CPU和网卡队里一一对应。
升级完以后,Redis的整体平均响应时间确实变短了,但是仍然会存在一些响应慢的情况出现,经过分析多张监控图的现象,我们发现Redis的QPS一直很稳定。
Redis可以说是一个内存级数据库,受限于物理内存的大小,我们会限制Redis对内存的使用,这在Redis中主要体现在以下两个方面:
1、删除已经过期的Key;
2、内存使用达到maxmemory上限时触发内存溢出控制策略;
在一个大的项目中,使用了全缓存模型,即,所有数据都会经过cache。简单分层:应用->内存缓存->redis缓存->数据库。是一个典型的多读写少的场景,并且数据量。请求量非常大。总结了一些使用经验,供参考。