bert82503
- 浏览: 120205 次
- 性别:
- 来自: 杭州
-
最新评论
-
793059909：
“5分钟里到底有多少个空闲池对象被循环地使用过。根据应用QPS ...
[线上问题] "Redis客户端连接数一直降不下来"的问题分析解决 -
793059909：
反复研读很多遍，但有一点一起没有想明白：如果是因为FIFO，为 ...
[线上问题] "Redis客户端连接数一直降不下来"的问题分析解决 -
bert82503：
liubey 写道多谢，很棒！ 客气~
[线上问题] "Redis客户端连接数一直降不下来"的问题分析解决 -
liubey：
多谢，很棒！
[线上问题] "Redis客户端连接数一直降不下来"的问题分析解决 -
bert82503：
chembo 写道 专业！过奖～
[线上问题] "Redis客户端连接数一直降不下来"的问题分析解决
文章列表
2016-05-06中午11:56，收到“[sentry2]2016-05-06 11:56:09 xxxxxxhost xxx.xxx.xxx.xxx 内存使用已达到90.18%”报警。首先在脑海浮现的，应该哪里出现内存泄漏了。
一、确认问题
马上到 Sentry 监控系统查看了该服务的“服务器监控”指标，发现其中2台机器的内存使用量都超过了90%，另外2台尽然没有监控数据（以前是有的）。
对于另外2台服务器没有监控数据，只好先登上去查看确认一下喽。通过“free -m”确认，线上服务器总内存共 7872MB，使用了 7098MB，还有 773MB（= 406 + 151 ...
【压测环境】
操作系统： Ubuntu 14.04 LTS
Linux版本： 3.13.0-24-generic x86_64 GNU/Linux
处理器： 4核的 AMD Athlon(tm) II X4 640 Processor @ 800MHz
机器内存：共 8GB，已使用 6GB，未使用 2GB，交换区 未使用
Redis版本：2.8.17
Redis内存：500MB
【压测结果】
压测原生的 Redis 性能（非Java客户端），结果如下：
hset 和 hget 都能在 4ms 之内完成，且每秒并发处理量都在 7.5万个请求之上；
hmset 和
MyBatis如何防止SQL注入
[摘自] mybatis防止sql注入 - chaoge
SQL注入是一种代码注入技术，用于攻击数据驱动的应用，恶意的SQL语句被插入到执行的实体字段中（例如，为了转储数据库内容给攻击者）。[摘自] SQL injection - Wikipedia
SQL
在Nginx上使用Lua脚本能做很多有价值的事情，比如生成请求的唯一标识(排查问题)、统一的权限校验、限流防洪(保证服务正常可用)等。
Lua是什么？
Lua是一种轻量级的多范式编程语言，其被设计为一种可扩展的语义脚本语 ...
本文主要记录自己在“从Nginx源码构建、编译并安装”过程中遇到的一些问题及详细步骤，通过以下方式构建的Nginx集成了 SSL、Lua、Nginx Upstream Health Check、解压缩 功能。
# 1. 下载安装包（http://nginx.org/en/download.html）
wget http://nginx.org/download/nginx-1.7.10.tar.gzwget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-
【问题背景】
前几天，我们上线了“基于’Nginx + Lua‘实现的统一权限校验功能”。该功能需要Nginx守护线程定期地从MySQL加载“合作方数据”，我们直接在Lua文件里写死了MySQL等配置信息（硬编码），然后通过一个“中间配置文件”手动修改来针对不同的部署环境选择不同的数据源。
这里有个坑：当开发和运维都忘记修改这个“中间配置文件”时，部署到不同的环境指向的数据源确一样的，会导致验证失败错误。默认是指向线上数据源，当我们部署完线上之后，确认一切正常之后，就立马着手部署测试联调环境，结果都为了要修改这个“中间配置文件”（部署完成后，没有通过本地curl确认，其实这样可以减少犯错 ...
前几天发现，线上portal “策略中心”的“证据管理”页面加载很慢。经排查发现，是由于 riskbase_core 库的 evidence 表未对 gmt_create 创建索引 和 evidence_details 表未对 refuuid 创建索引引起（因为查询条件涉及到这些字段），导致SQL执行时间要 1分钟+。 # 查询SQLselect d.type,d.value,e.fraud_type,e.evidence_time,e.evidence_origin,d.uuid,d.refuuid from evidence_details d inner join evidence e ...
仔细聆听别人的声音，也努力表达自己对技术的看法，并随时将你的宝贵经验与社区分享，这样你不仅能获得技术上的提高，还可以得到整个社区的认可和尊敬。
14.4.3发言的礼仪
通过适当的礼仪和友好的行为方式，可以更有效地通过邮件列表解决项目中的问题。Eric Raymond对此有非常精彩的讨论，见其《提问的智慧》一文，以下部分观点就来自于该文。
1. 提问
新加入一个社区总有许多东西是你不了解的，通常我们会阅读手册和源代码解决大部分的疑问。但仅靠个人，总有无法解答的问题，在邮件列表上提问是更直接有效的解决问题的方式。
社区的开发者总是乐意帮助别人解答问题的，虽然黑客通 ...
前段时间，上线了新的 Redis缓存（Cache）服务，准备替换掉 Memcached。
为什么要将 Memcached 替换掉？
原因是 业务数据是压缩后的列表型数据，缓存中保存最新的3000条数据。对于新数据追加操作，需要拆解成[get + unzip + append + zip + set]这5步操作。若列表长度在O(1k)级别的，其耗时至少在50ms+。而在并发环境下，这样会存在“数据更新覆盖问题”，因为追加操作不是原子操作。（线上也确实遇到了这个问题）
针对“追加操作不是原子操作”的问题，我们就开始调研有哪些可以解决这个问题同时又满足业务数据类型的分布式缓存解决 ...
4. 一个大坑：若实例化 JedisShardInfo 时不设置节点名称（name属性），那么当Redis节点列表的顺序发生变化时，会发生“键 rehash 现象”
使用BTrace追踪redis.clients.util.Sharded的实时状态，验证“Jedis分片机制的一致性哈希算法”实现；
发现一个致命坑：若JedisShardInfo不设置节点名称（name属性），那么当Redis节点列表的顺序发生变化时，会发生“键 rehash 现象”。见Sharded的initialize(...)方法实现：
（I） this.algo.hash("SHARD-" ...
本文主要剖析 Apache Commons Pool 的“空闲对象的驱逐检测机制”的实现原理。
以下面3个步骤来循序渐进地深入剖析其实现原理：
启动“空闲对象的驱逐者线程”（startEvictor(...)）的2个入口
在启动时，创建一个新的" ...
官方对Redis的阐述：
Redis is an open source, BSD licensed, advanced key-value cache and store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets, sorted sets, bitmaps and hyperloglogs.
前些天，线上出现“服务端长连接与客户端短连接引起Nginx产生大量"TIME_WAIT"状态的线程”的问题分析解决”，这个是由于“服务端使用HTTPs长连接，而客户端使用短连接”引起。这几天，发现Nginx与Tomcat之间也存在同样的问题，原因是两边的相关配置参数不一致引起的。（这是心细活！）
先说说服务为什么使用HTTPs长连接技术？有如下几个原因：
对响应时间要求较高；
服务走的是公网，客户端与服务端的TCP建立的三次握手和断开的四次握手都需要40ms左右(真实数据包计算出来的)，共需要80ms左右；
每个接入方使用的IP就若干个，需要建立的请求 ...
近期，线上Nginx服务器的TPS未超过100，但其Writing、Active连接数有时却超过了300。因为服务对响应时间要求较高，同时每个调用方使用的IP地址有限（即总的不同的连接地址有限），所以使用HTTPs长连接技术。（HTTP长连接与短连接）
问题现象：使用"sudo netstat -antp | grep 80"发现，存在大量的"TIME_WAIT" socket等待中断请求确认的线程（8000+）原因：使用Wireshark分析tcpdump.txt发现，eleme使用短连接请求（非长连接，Keep-Alive），而服务器端使用 ...
要想快速使用Wireshark分析请求数据包，可参考其本地文档《Wireshark过滤器语法与引用 HELP-Manual Pages-Wireshark Filter》和《一站式学习Wireshark》系列文章。
如何使用tcpdump在Linux服务器下抓取网络数据包
【示例】
1. 抓取8080端口上的所有网络数据包
sudo tcpdump -i eth0 -n port 8080 -w keepalive-http.txt
2. 抓取80端口和特定源或目标地址的所有网络数据包
sudo tcpdump -i eth0 -n port 80 and h ...