最新文章

采集自各技术站点的近期文章。

IT 后端/ 2012-11-01 13:22:19 / 累计浏览 3,500

稳定性思考-强弱依赖2

这篇文章从一个实际问题切入：在微服务架构中，如何为弱依赖（如Cache）设置合理的“并发请求数阈值”？作者的分析思路很清晰，核心目标是实现高QPS下的资源消耗最小化，即“高QPS，少线程”。作者通过一个Cache访问案例，结合公式 QPS=1000/RT * threadNum，做了生动的故障推演。正常时1个线程就能支撑400QPS；一旦Cache故障、RT飙升至3000ms，理论上就需要1200个线程，这会导致调用方线程池耗尽、频繁FullGC，陷入恶性循环。为此，文章提出的核心方案是：限制访问弱依赖的线程数。例如，将阈值设为10。这样在上述故障中，调用方只会阻塞10个线程，整体服务保持正常，实现优雅降级。结合超时设置，能形成更有效的流控策略。那么阈值设多少？文章给出了计算方法：根据可接受的RT（如100ms）和目标QPS（400）反推，得到 threadNum = 400 * 100 / 1000 = 40。作者也分享了经验数据：平均50ms的APP，阈值一般不超过60。文章最后点明，响应时间变长往往源于排队，而系统的最高QPS由瓶颈资源决定，盲目增加线程未必有用。

本机暂存

IT 后端/ 2012-11-01 13:22:01 / 累计浏览 3,570

稳定性思考-强弱依赖

这篇讲的是系统稳定性中一个核心却容易被忽视的点：如何正确处理系统间的依赖关系。作者从淘宝复杂的系统依赖场景出发，将依赖清晰地划分为“强依赖”与“弱依赖”，并剖析了二者对系统稳定性的迥异影响。对于强依赖，文章指出其风险在于“一荣俱荣，一损俱损”。除了主张通过扩展通道来解耦，作者更通过一个生动的分流压测案例揭示了关键发现：一个单机容量为4的系统，在被过载压垮后，其容量会急剧下降至约2.5，且自身难以快速恢复。这源于资源耗尽导致的线程堆积与频繁Full GC，深刻说明了对下游依赖系统进行“流量保护”的必要性。文章接着探讨了更优的“弱依赖”模式。它细分为两种场景：一是主流程无需等待结果的异步化调用；二是需要等待结果但通过设置超时与最大并发阀值来熔断保护。这两种方式都能在B系统故障时，确保核心链路A的稳定运行。整体而言，作者用从理论到压测实证，再到具体技术方案的递进逻辑，为如何设计高可用系统提供了极具操作性的指导。

本机暂存

IT 算法/ 2012-11-01 13:20:58 / 累计浏览 2,352

讨论：一则并行聚合计算方案的设计

这篇讲的是作者在构建一个实时数据看板时遇到的并行聚合计算难题。场景很具体：一个最多10万元素的数据集，每秒会收到数百到数千次字段修改（远多于增删操作），系统需要实时计算并维护多达50条聚合规则（如求和、平均、加权平均）在最多5层分组下的完整结果树。所有数据都在内存中，要求能立刻响应任何滚动查看。作者首先实现了一个高效的串行方案：让聚合器监听集合变动，利用更新前后的值进行差值计算，避免全量重算。但面对更高的性能需求，他开始探索并行化。简单的“每次变动后并行计算”不可行，会导致持续高负载和并发错误。他尝试借鉴Erlang的Actor模型，将每个聚合器独立为消息驱动单元，但随之带来了新问题：在传递元素属性更新消息时，是否需要携带整个元素“快照”？直接携带开销太大，不携带则可能因并发修改导致聚合计算拿到中间状态的数据。作者发现，或许只有分组字段变更时才需要快照，这大幅降低了开销。文章详细剖析了一个从串行到并行演进中的经典权衡：如何在保证实时性的同时，平衡计算延迟、系统负载与数据一致性。作者不仅给出了清晰的问题定义，更分享了思考路径与初步尝试，为面临类似挑战的读者提供了宝贵的讨论起点。

本机暂存

IT 开发者/ 2012-11-01 13:20:04 / 累计浏览 4,291

当我加入项目时，我要了解什么

这篇文章讲述了一位经验丰富的技术人员在频繁加入新项目时，如何快速把握全局并投入工作的核心方法。作者认为，理解项目应从三个层面循序渐进：首先是业务，目标不是纠缠细节，而是能在五分钟内清晰说明“这个系统是做什么的”，避免将技术细节与业务混杂讲解。在技术层面，作者主张先宏观后微观。先确认整体技术栈（如Java或.NET），再借助一张系统架构图理清外部集成与内部模块划分。对于模块和层次，作者特别指出很多系统的问题在于模块职责模糊、依赖混乱，而清晰的分层结构是现代系统的关键。深入细节时，应从集成点入手（如了解MQ中传输的是XML），再探查源码目录结构，但不必在初始阶段过于深入。最后，团队运作方式同样重要，例如站会、迭代会议的时间安排，是否存在常规的Code Diff或Session分享墙，以及与客户是否有定期沟通机制。作者通过这些问题往往能快速识别团队协作中的潜在问题。整体来看，这套结合业务、技术与团队维度的系统性了解路径，能帮助开发者在一到两天内建立对项目的完整认知，为后续高效协作打下基础。

本机暂存

IT 开发者/ 2012-10-29 13:26:12 / 累计浏览 6,095

应届生选择大公司还是小团队

这篇文章是针对一位应届硕士的典型困惑给出回应：在互联网巨头稳定的非核心岗位，与一家发展不错但前景不明的团购小公司之间，该如何选择。作者“怪蜀黍”的核心观点很明确：通常建议应届生优先进入大公司。他从“心态培养”和“职业路径”两个角度分析。一方面，他认为应届生普遍缺乏在小公司所需的主动性、自学能力和挫折承受力，过早进入小公司容易产生“一切都怪环境不好”的抱怨心态，而大公司的规范环境则迫使职场人直面问题，有助于建立更平稳的职业心态。另一方面，作者指出大公司能有效锻炼“为人处事与沟通方式”，这是从平均值来看的普遍优势。更重要的是，他点明了一个现实的路径选择：先进大公司，打造一份漂亮的履历，之后跳槽去中小公司相对容易；反之则门槛要高得多。他将大公司比作一剂“麻药”，既捆住手脚又提供优渥待遇，容易消磨斗志，但也正因如此，它为职场新人提供了宝贵的缓冲期和观察窗。最后，作者也赞同“大中小公司都做一圈”的经历，认为这能帮助个人最终认清自己想要什么、适合什么。

本机暂存

IT 数据库/ 2012-10-29 13:14:40 / 累计浏览 3,423

MySQL5.6.7-rc index condition pushdown代码解读

这篇讲的是MySQL 5.6.7-rc版本中Index Condition Pushdown（ICP）特性的源码探索之旅。作者对ICP很感兴趣，于是决定跟踪代码，一探究竟。文章首先通过对比不同索引结构下的`EXPLAIN`执行计划，直观展示了ICP的效果。在单一字段索引下，查询需要先通过索引找到主键，回表取完整数据，再用其他条件过滤。而创建了`(name, info)`联合索引后，像`info like '%1'`这样的条件，能在索引层就先被过滤掉，从而减少了回表次数，执行计划里也不再出现“Using where”。最关键的“真相”在代码里。作者一路跟下去，找到了存储引擎层比较WHERE条件的位置，并直接给出了函数调用栈：从`row_search_for_mysql`开始，通过`row_search_idx_cond_check`，最终调用到`innobase_index_cond`执行条件判断。这个调用链清晰地揭示了ICP是如何在InnoDB引擎内部、在通过二级索引读取记录时，提前将不满足条件的数据过滤掉的，避免了不必要的回表操作，这正是该特性的巧妙之处。

本机暂存

IT 数据库/ 2012-10-28 23:29:02 / 累计浏览 9,701

深入浅出INNODB MVCC机制与原理

这篇讲的是MySQL InnoDB存储引擎中一个核心且容易让人混淆的机制——多版本并发控制。作者从数据库事务的基本概念（如隔离性、锁）切入，清晰地引出了MVCC存在的必要性：在保证数据一致性的同时，最大化提升并发处理能力。文章的精华在于对MVCC实现原理的拆解。它没有停留在常见的“创建时间与删除时间”的简化描述上，而是直接指出了这个广为流传的说法存在两处不准确。作者通过`SHOW ENGINE INNODB STATUS`等命令，详细解释了InnoDB在行数据中实际隐藏的三个关键字段：`DB_TRX_ID`（事务ID）、`DB_ROLL_PTR`（回滚指针）和`DB_ROW_ID`（行ID），并阐明了它们各自的职责。更进一步，文章通过具体的事务ID示例，图形化地演示了在“可重复读”隔离级别下，一条SQL查询如何根据这三个字段和“Read View”（读视图）来判断数据的可见性，从而实现“读不阻塞写，写不阻塞读”的高效并发。它特别纠正了“删除”操作的误解，指出MVCC中的“删除”仅是标记，真正的物理删除发生在后续清理阶段。这篇文不仅梳理了基础知识，更致力于帮读者建立对InnoDB MVCC机制更准确、更底层的理解框架，对于想弄明白“快照读”背后究竟发生了什么的开发者来说，提供了非常扎实的技术解析。

本机暂存

IT 数据库/ 2012-10-28 23:28:33 / 累计浏览 5,438

mysql系统变量专题学习

这篇讲的是MySQL系统变量的深度解析。作者发现官方中文文档简略，网络资料零散，于是花了两周时间，结合查阅和亲手测试，系统梳理了这些决定MySQL配置与性能的关键变量。文章没有停留在罗列定义上，而是深入到每个变量的作用域（全局或会话）和值域，并辅以实战配置与效果演示。比如，详细讲解了如何启用和解读慢查询日志（`log_slow_queries`），从而捕捉性能瓶颈；剖析了`concurrent_insert`不同取值下，MyISAM表读写并发行为的差异；还澄清了`log_warnings`等较少被讨论的变量。作者通过具体的案例（如一条查询被记录进慢日志的完整输出），让抽象的变量配置变得可见、可验证。这对于需要调优MySQL性能、理解其内部机制，或是寻找一份可靠变量参考手册的开发者和DBA来说，提供了一份扎实、可操作的指南。

本机暂存

IT 数据库/ 2012-10-28 23:26:25 / 累计浏览 8,524

为什么字段尽可能用NOT NULL，而不是NULL

这篇探讨的是MySQL数据库字段类型选择的核心争议：为什么推荐使用NOT NULL而非NULL。作者从常见的优化建议切入，指出许多文章只抛出结论却未解释缘由，于是从技术细节上深入对比了两者的关键差异。首先，文章澄清了一个普遍误解：很多人误以为NOT NULL会增加存储空间，实际上恰恰相反——NULL列需要额外一个字节作为是否为空的标志位，导致存储开销上升。根据MySQL官方文档，NULL列在行中占用更多空间，尤其在MyISAM表中，每个NULL列甚至引入比特级的额外负担，向上取整到字节级别。更重要的差异体现在查询优化层面。MySQL对可空列的处理更为复杂，难以高效进行索引统计和值比较。例如，可空列

本机暂存

IT 数据库/ 2012-10-28 23:25:28 / 累计浏览 6,254

InnODB和MyISAM索引统计集合

这篇讲的是MySQL优化器如何收集和使用索引统计信息来做出查询决策。作者从`myisam_stats_method`变量入手，详细解释了InnoDB和MyISAM如何统计“平均数值组”——即拥有相同索引键值的平均行数。关键点在于，这个平均数值组越小，说明索引的区分度（Cardinality）越高，优化器就越倾向于使用它。文章通过一个实例直观展示了这一点：一张千行表的主键Cardinality为966，计算出的平均数值组约为1.04，意味着每个主键值平均只指向约1行数据，索引效率很高。文章的重点对比在于两种存储引擎处理NULL值的策略差异。通过`NULLS_EQUAL`、`NULLS_UNEQUAL`和`NULLS_IGNORED`三种统计方法，优化器会对NULL值有不同的“看法”，从而影响平均数值组的计算结果。例如，`NULLS_EQUAL`会把所有NULL视为相同，这在NULL值非常多的情况下会大幅降低Cardinality，导致优化器错误地放弃本应使用的索引。而`NULLS_UNEQUAL`（MyISAM的默认策略）则将每个NULL视为独立的组，更适合NULL值不占主导的场景。理解这些统计信息的收集机制，能帮助我们更清晰地认识为什么`Cardinality`值越大、索引通常越好，并在设计表结构或排查索引失效问题时，考虑到NULL值分布可能带来的影响。

本机暂存

IT DevOps/ 2012-10-28 23:22:51 / 累计浏览 2,550

马化腾：灰度法则的七个维度全文

马化腾在这次演讲中，系统回顾了腾讯14年的经验与教训，并针对开放平台生态中“如何持续运营好产品”这一核心难题，提出了他思考的结晶——“灰度法则”。他认为，互联网产品像生态中的物种，需要在快速变化中找到平衡点，而非追求僵化的完美。为此，他从需求度、速度、灵活度、冗余度、开放协作度、进化度、创新度七个维度，阐释了构建“生物型组织”的关键。例如，在需求度上，他强调用“10/100/1000法则”（每月10次用户调查、100篇博客、1000条反馈）来脚踏实地地理解用户；在速度上，主张“小步快跑，快速迭代”；在冗余度上，则以微信的诞生为例，说明允许多个团队内部试错、容忍必要浪费的价值。这篇演讲的核心观点是，创新并非刻意为之，而是开放协作、主动进化、容忍失败的生物型组织自然生长的结果。对于创业者而言，这七个维度提供了一个在不确定生态中把握确定性的思考框架：如何从“追求精准控制”转向“构建多样性的灰度空间”，从而让创新持续涌现。

本机暂存

IT 数据库/ 2012-10-28 23:22:03 / 累计浏览 2,712

Redis命令行操作指南

这篇讲的是Redis命令行操作的全面指南。作者从连接数据库、基本键操作出发，系统梳理了对String、List、Set、Zset（有序集合）、Hash这五种核心数据类型的所有常用命令。它不只是罗列，而是结合了具体的场景。例如，SET/GET用于基础的键值存取，SADD/SMEMBERS用于集合成员的增减与遍历，ZADD/ZRANGE则用于需要按分数排序的场景。文章还涵盖了持久化（如SAVE/BGSAVE）和远程服务器控制（如INFO/MONITOR）等运维命令。对于Redis使用者来说，这就像一份随时可查的“命令字典”，将官方文档中分散的命令按功能和数据类型组织起来，提供了清晰的参照。无论是初学者熟悉接口，还是开发者日常查阅特定命令的用法，都能从中快速找到答案。

本机暂存

IT AI/ 2012-10-28 23:21:18 / 累计浏览 3,699

国内外旅游电子商务个性化推荐系统研究

这篇讲的是如何让旅游网站更懂你。当前多数旅游电商网站内容同质化严重、服务千篇一律，导致游客选择困难、预订转化率低。文章从这一痛点切入，以国内外发展现状为背景，深入探讨了个性化推荐系统在旅游电商中的应用。作者首先梳理了国内（如携程、艺龙）与国外个性化服务从学术研究走向产业应用的历程。核心在于分析影响旅游消费者决策的经济与非经济因素——从收入、价格到动机、个性特征等，这些因素共同构成了个性化推荐的依据。文章重点对比了传统旅游电商与个性化推荐系统的区别：前者以交易效率为核心，后者则以提供个性化服务为前提，通过双向沟通和精细市场细分来设计产品。研究最终落脚于个性化推荐系统的主要功能与体系结构分析，并进行了模拟应用。其目标是帮助游客高效决策，获得更好的旅游体验，从而提升网站竞争力与用户忠诚度。

本机暂存

IT 设计/ 2012-10-28 23:20:41 / 累计浏览 79,514

十个最容易犯的用户体验错误及规避方案

这篇文章深入剖析了产品设计中最常被忽视的十个用户体验陷阱。作者指出，很多团队空有漂亮的界面，却忽略了产品是否真正解决了用户的问题。比如，过早投入设计而不验证市场需求，或是功能堆砌导致产品失去焦点，像Dropbox和Instagram那样在单一功能上做到极致才是正解。文中特别强调，可用性测试能带来巨大回报——一个支付按钮文案的优化曾为某电商提升了3亿美元的年销售额。同时，诸如垃圾表单设计、技术人员撰写文案、技术成为体验障碍等细节问题，也常常在不经意间赶走用户。作者的核心观点是，良好的用户体验并非一次性投资，而是一种贯穿产品始终的态度和文化。它要求从一开始就以用户为中心，通过“精益”方式快速验证，并在每一个微小接触点上精心打磨。

本机暂存

IT 前端/ 2012-10-28 23:20:05 / 累计浏览 2,990

构建web前端异常监控系统–FdSafe

这篇讲的是如何构建一套名为“FdSafe”的前端异常监控系统，专门解决线上页面JavaScript报错或样式丢失等“裸奔”问题。作者从“让用户和Boss在发现问题前就修复问题”的实际需求出发，介绍了系统的两大核心监控思路：针对JS异常，利用JavaScript动态特性，通过注册时给所有函数统一包裹try-catch来无侵入地捕获错误，并上报详细的错误上下文；针对样式丢失，则采用定时截图并与历史图片进行OpenCV相似度对比的方法，当差异超过阈值时触发报警。整个监控系统的后台基于Node.js搭建，负责接收前端上报的异常和定时抓取分析页面，异常一旦超限便会通过短信或邮件通知负责人。文章不仅给出了具体的技术实现路径（如cvCompareHist算法），也分享了插件化扩展的设计思想，为前端同学搭建自己的监控体系提供了清晰的框架和可落地的思路。

本机暂存

IT 数据库/ 2012-10-26 22:51:07 / 累计浏览 5,669

MySQL vs MariaDB vs Percona 之TPCC性能测试

这篇测评比较了MySQL、MariaDB和Percona在TPCC基准测试中的性能表现。作者搭建了统一的硬件环境，通过自动化脚本运行了严格的1000仓库规模测试，重点对比了不同版本（如MySQL 5.6、Percona 5.5/5.6、MariaDB 5.5）以及关键配置差异（如独享表空间、InnoDB Buffer Pool实例数）对性能的影响。测试结果显示，Percona 5.6（配置为独享表空间且Buffer Pool实例数为1）取得了最高的TpmC（每分钟事务数），性能优势显著。同时，测试观察到一个趋势：在测试的线程数范围内，并发线程数增加通常能带来更高的TpmC效率。相比之下，文章也指出本次测试并未深入涵盖各数据库版本宣称的所有新特性。对于需要高事务处理能力的OLTP场景，文章数据表明Percona 5.6是一个值得考虑的高性能选项。

本机暂存

IT 设计/ 2012-10-26 22:47:58 / 累计浏览 5,187

设计模式原则总结

这篇文章系统梳理了面向对象设计中的七大核心原则，从单一职责到迪米特法则，为开发者提供了一份清晰的“设计心法”参考。作者没有停留在概念罗列，而是用通俗的语言点明了每个原则的实质：比如“开放-封闭”原则强调对扩展开放、对修改关闭，是应对需求变化的基石；里氏代换原则则为继承体系划定了行为边界，确保子类能无感替换父类；而依赖倒置原则提倡面向接口编程，正是解耦高层与底层模块的关键。文章特别区分了合成/聚合复用原则中“聚合”（弱拥有关系）与“合成”（强拥有、生命周期一致）的微妙差异，这对选择正确的复用方式至关重要。所有解释都紧扣实际编码场景，如接口隔离原则直指“避免接口臃肿”和“最小化依赖”的痛点。文末注明内容源自经典书籍《大话设计模式》，为总结的权威性提供了背书。掌握这些原则，能帮助我们更清醒地判断代码结构，写出更健壮、可维护的系统。

本机暂存

IT AI/ 2012-10-26 22:45:41 / 累计浏览 2,687

“connect the dots” 随想

这篇随想以乔布斯经典的“connect the dots”理念为切入点，探讨了成功叙事之外，个人成长与积累的本质。作者指出，许多年轻人在选择面前感到迷茫，往往源于对“有形”功利目标的过度追求，而忽视了日常积累中那些无形的“点”。文章进而从做人、交友与专业选择三个维度展开论述。做人需以诚信与自省为根基，成为值得信赖的人；交友则要追求真诚互助与价值输出，如同纽曼所描述的理想学习共同体。这两者是“connect the dots”的基础，但目的并非直接兑换利益。在专业方向上，作者结合历史案例，强调突破视界局限、寻找良师与平台、以及持之以恒的重要性。整篇文章的核心观点在于，人生关键的“连接”往往发生在回望之时。那些看似无目的的日常修养、真诚交往与专业沉淀，才是未来得以串联成图的关键节点。

本机暂存

IT 后端/ 2012-10-26 22:43:03 / 累计浏览 7,225

使用gdb调试运行时的程序小技巧

这篇讲的是开发者用GDB调试正在运行的程序时，那些常常让人头疼的场景和作者摸索出的实用解法。文章开门见山，直指三个高频痛点：如何在不中断服务的情况下探查程序状态、如何高效地批量查看变量和Core文件、以及如何“透视”链表或树这类复杂数据结构。作者没有停留在理论，而是给出了一套完整的“武器库”。针对第一个场景，他分享了一个精巧的`runstack.sh`脚本，通过一行命令就能附加到目标进程，查看甚至修改全局变量的值，而无需重启服务。对于需要批量操作的场景，他展示了如何编写GDB脚本（.gdb文件）来一次性执行多个调试命令，以及如何改造脚本来快速分析多个Core文件的堆栈，快速归类问题。文章还附上了完整的测试代码和用例，从编译到执行，手把手演示效果。这些技巧源于对Systemtap等工具复杂性的规避，和对生产环境调试需求的深刻理解。作者提供的不仅是几个命令，更是一套结合了Shell与GDB的轻量级工作流，能帮助开发者在复杂的线上环境中更安全、更高效地定位和解决问题。

本机暂存

IT 设计/ 2012-10-26 22:31:11 / 累计浏览 2,144

组合还是继承，这是一个问题？——由模式谈面向对象的原则之多用组合、少用继承

这篇文章探讨的是面向对象设计中一个经典的选择困境：扩展类的功能时，应该优先使用组合还是继承？作者从设计模式为何有效的根本问题出发，将模式作为生动的案例，来阐释“多用组合、少用继承”这条重要原则。文章的核心观点是，继承看似直接，实则暗藏多个风险：它会强制子类接受父类所有公开和受保护的方法，可能引入无用甚至冲突的功能；容易导致类体系的无限膨胀；并且在编译期就固定了类型关系，缺乏运行时灵活性。文中通过一个具体而有趣的例子来印证这些观点：我们需要一个既能像HashMap那样通过key取值，又能像ArrayList那样按顺序取值的“ListMap”。作者首先展示了一个继承自HashMap的实现，它虽然简单，但朋友使用时因未重写`values()`方法而得到了混乱的顺序，直接暴露了继承“全盘接受”的危害。随后，文章给出了一个基于组合（内部持有HashMap和ArrayList）的改写方案，它更安全、更可控，只暴露必要的方法。最后，文章引入了Adapter模式和Decorator模式作为例证，展示了组合如何优雅地解决多重继承限制和类爆炸问题，尤其是Decorator模式通过对象组合动态添加职责，其设计思路令人叫绝。整篇文章通过从问题到代码实践，再到模式印证的清晰脉络，让“优先组合”这一原则变得具体可感。

本机暂存