最新文章

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

IT DevOps/ 2014-11-30 23:26:11 / 累计浏览 2,053

实用命令行工具详解(二)—siege

这篇讲的是Linux下的负载测试工具siege如何模拟真实用户行为。文章开篇就点明了它与Apache ab的关键区别：siege能从URL列表随机请求，更适合仿真多用户并发负载，而ab则在追求极致性能基准时更精确。文章详细展示了siege的多种实战用法。比如，你可以用 `siege -c 500 -r 50 -f url.txt` 模拟500个用户重复请求50次；也可以用 `-t10M` 参数让压测持续10分钟。它甚至能从服务器的access.log中提取URL，用来复现历史访问场景，这对于重现问题非常实用。对于测试结果，文章逐一解读了输出指标，像“Transaction rate”即我们常说的QPS，“Response time”反映网络连接速度。最后部分还梳理了关键参数，如 `-c` 控制并发量、`-d` 设置请求间隔、`-l` 保存日志等，帮助读者根据自身环境灵活配置。整体上，这篇文章没有停留在理论介绍，而是通过具体命令和输出示例，手把手地带读者用起来。对于需要快速评估Web应用压力承受能力的开发者来说，这是一份清晰的速查手册。

本机暂存

IT 后端/ 2014-11-30 23:24:22 / 累计浏览 3,056

实用命令行工具详解(一)—curl

开发web应用时，接口调试是高频操作，虽然工具有很多，但像curl这样轻量又全能的命令行工具确实值得一用。这篇文章系统梳理了curl在日常开发中的实用场景，从最基础的网页抓取说起，讲解了如何用`-o`参数保存文件，用`-i`或`-I`快速查看响应头信息，以及通过`-L`自动处理页面重定向。对于更深入的调试需求，文章重点展示了`-v`参数的强大之处——它能完整呈现一次HTTP通信的全过程，包括TCP连接和请求头细节，是排查网络问题的利器。而在接口联调时，如何发送POST请求、自定义User-Agent或携带Cookie，这些常见操作文中都给出了明确的命令示例。特别值得一提的是，文章还介绍了一个很实用的技巧：如何使用`-w`参数精确测量接口的连接时间、开始传输时间以及总耗时。这三个指标对于诊断网络状况和评估系统性能非常有帮助。通过对比单引号与双引号在变量替换上的不同行为，也侧面提醒了我们在编写脚本时需要注意的细节。全文围绕实际命令展开，几乎没有空泛的理论，对于想快速掌握curl核心用法的开发者来说，这是一份非常直接的参考。

本机暂存

IT 算法/ 2014-11-30 23:23:24 / 累计浏览 12,368

如何使用1M的内存排序100万个8位数

这篇讲的是如何在仅有1MB内存的约束下，对100万个8位整数进行排序的经典算法难题。问题最初源于Stack Overflow，看似无解——毕竟100万个数直接存储就需要超过1MB的空间。文章介绍了一种巧妙的解法核心：不直接存储排序后的每个数字本身，而是利用它们已排序这一特性，转而记录相邻数字之间的差值。由于这些差值平均很小，理论上可以用大约7位（bit）来表示一个差值，总计约0.875MB，从而在1MB内存内完成编码存储。实现上采用了高效的归并排序，并利用算数编码或哈夫曼编码对差值进行压缩编码。作者还分享了完整的339行实战代码，并提到了其他程序员的不同解题思路，展现了算法在极端约束下化不可能为可能的魅力。

本机暂存

IT DevOps/ 2014-11-30 23:22:44 / 累计浏览 1,956

基于DRBD的高可用NFS解决方案分析

这篇讲的是如何用 DRBD 和 NFS 搭建高可用文件共享方案的一次实践与踩坑。作者从分析 NFS 协议（特别是 NFSv4 对迁移和故障恢复的定义）出发，设计了一个方案：底层用 DRBD 实时镜像块设备，在其上建立文件系统，再通过 NFS 共享，期望在主机故障时能实现业务无感知的切换。按照这个思路，作者搭建了测试环境，模拟在线业务时进行 DRBD 倒换、NFS 重启和 IP 漂移。理论上，NFS 协议的“grace time”机制应该能处理服务端重启，让客户端用旧的文件句柄重新连接时依然能定位文件。但实际测试结果是：客户端报出“NFS句柄无效”的错误。作者分析指出，关键问题在于 DRBD 镜像的块设备在两台主机上各自挂载后，生成的 inode 分配并不一致。尽管文件系统数据完全一样，但 NFS 服务端是通过宿主文件系统看到共享目录的，当发生切换后，对端无法正确解析客户端原有的、基于旧 inode 信息构造的文件句柄，导致访问失败。文章最后也坦诚了验证未能完全成功，并提出了后续可以从 NFS 源码层面探索直接共享 DRBD 设备内容的思路。

本机暂存

IT 数据库/ 2014-11-30 23:22:09 / 累计浏览 7,553

存储基础知识之——硬盘接口简述

这篇文章梳理了从经典的IDE到现代FC、iSCSI等七种主要硬盘接口技术的演进与区别。文章指出，IDE（即并行ATA）因性能和速率的局限，已随SATA（串行ATA）的兴起而退役。SATA目前是消费级市场的主流选择，其接口速率已迭代至第三代。在企业与高性能领域，文章则对比了SCSI体系及其继任者。SCSI-3虽能提供160MB/s带宽并支持多设备，但其并行架构已发展为串行的SAS接口，后者不仅提供更高的传输速率（如第二代SAS达6Gbps），还通过点对点连接简化了部署，并能兼容SATA设备。更为关键的是，文章详解了如何通过网络化突破本地存储的物理限制：iSCSI技术将SCSI命令封装于TCP/IP协议中，利用现有网络实现远距离、大规模的存储区域网络（SAN）；而光纤通道（FC）则以其高速（可达16Gbps）、低延迟和长距离传输（最远10公里）的特性，成为构建高性能企业级SAN的核心选择。整体来看，这篇文章从接口的物理形态、传输协议到应用场景，系统性地梳理了存储连接技术的关键差异，为理解存储系统架构和选型提供了清晰的脉络。

本机暂存

IT 后端/ 2014-11-30 23:21:13 / 累计浏览 2,870

Openstack Swift简介

这篇讲的是 OpenStack 的核心对象存储服务——Swift 的设计哲学与实现原理。它要解决的核心问题，是如何在相对廉价的标准硬件上，构建出一个能承载海量非结构化数据的高可用、可无限扩展的存储系统。文章深入解析了 Swift 的几个关键设计。为了解决海量数据的寻址难题，它采用了一致性散列技术，并通过一个名为“Ring”的独特数据结构，将数据均匀映射到物理设备上，在增减节点时大幅减少数据迁移。更精妙的是其一致性模型：Swift 在 CAP 理论下选择了“最终一致性”，通过 Quorum 仲裁协议（默认配置3副本、写需2个成功）来平衡可用性与一致性，以适应读写频繁的互联网场景。其清晰的数据模型（账户/容器/对象）和对称、无单点的系统架构，则进一步支撑了其多租户和横向扩展能力。整体来看，文章从背景原理到架构细节，清晰地勾勒出了一个用软件层面的精巧设计（如一致性散列、Quorum协议）来弥补硬件简陋、并最大化可用性与扩展性的经典分布式系统范例。

本机暂存

IT 开发者/ 2014-11-30 23:19:01 / 累计浏览 2,809

关于Python的闭包和后期绑定

这篇讲的是Python开发者常掉进去的一个坑：如何正确理解闭包与后期绑定。作者从“Python程序员的10个常见错误”中引出话题，通过汇总维基百科、《Java编程思想》等不同来源对闭包的定义，最终聚焦于一个核心点——闭包是一个包含了变量和其绑定环境的完整整体。文章用一个经典的代码例子来阐明问题：用列表推导式生成一系列lambda函数，期望它们分别捕获不同的值，但实际调用时却都输出了最后的结果。这里的关键就在于Python的“后期绑定”特性——闭包中引用的变量，在函数被调用时才去环境中查找其值，而不是在定义时。因此，所有lambda函数捕获的都是同一个变量`i`，在循环结束后它的值是4。理解这一点，能帮助我们避免这类因延迟求值导致的诡异bug。文章不满足于给出定义，而是通过具体代码剖析了概念在实践中的真实表现，对厘清闭包机制很有帮助。

本机暂存

IT 后端/ 2014-11-30 23:18:03 / 累计浏览 4,564

OpenStack Swift源码导读之——业务整体架构和Proxy进程

这篇文章深入剖析了OpenStack Swift对象存储的业务整体架构与Proxy进程的实现细节。作者从Swift的源码目录结构入手，清晰地解读了proxy、account、container、object等各业务进程的职责划分。重点在于Proxy进程的业务处理逻辑。文章指出，理解其基于PasteDeploy的堆栈式WSGI架构是关键，每一层分工明确，最外层处理异常。Proxy进程通过解析请求URI和方法来识别资源类型，并借助控制器进行分发。其核心路由机制依赖于一致性哈希环，作者通过具体代码段（如get_nodes、get_part函数），展示了如何通过哈希计算将请求映射到特定的物理节点集合。此外，文章还揭示了Swift在保证数据高可用性方面的设计：通过引用NWR原则（如3写2读），并在make_requests等公用方法中实现“法定人数”判定，确保了分布式环境下写操作的可靠性。整个导读将抽象的架构设计与具体的代码实现相结合，为读者理解Swift内部如何协调请求、定位资源与维护数据一致性提供了清晰的路径。

本机暂存

IT 移动开发/ 2014-11-30 23:16:14 / 累计浏览 4,029

手机应用/服务器开发的一些总结(二)

这篇讲的是自定义TCP socket开发中的实践经验与方案对比。作者从Android客户端和服务器端两个维度展开，重点讨论了阻塞与非阻塞socket的选型及具体实现中的“坑”。 Android端部分，作者对比了传统阻塞socket与NIO的使用差异，特别分享了NIO在实际业务中遇到的问题。例如网络断线时`finishConnect()`可能长时间阻塞，解决方案是通过`setSoTimeout`设置合理超时。同时也指出了NIO下`channel.read`不同返回值（如-1表示关闭、0表示无数据）的准确含义，这些细节对稳定开发至关重要。 Server端部分，作者分析了从Python标准库`ThreadingTCPServer`到异步框架tornado与gevent的演进。他指出，tornado的异步IO虽然性能高，但业务代码不能阻塞，使用起来有一定痛苦；而gevent则兼顾了性能与编码便利性。基于此，作者还封装了`tkola`和`gkola`两个库，采用类似Flask的装饰器风格来简化TCP server开发，并提供了清晰的代码示例。总的来说，文章不仅梳理了不同场景下的技术选型逻辑，更分享了生产环境中的具体解决方案与开源工具，对从事移动端与服务器网络编程的开发者有较强的实用参考价值。

本机暂存

IT 移动开发/ 2014-11-30 23:13:54 / 累计浏览 4,685

手机应用/服务器开发的一些总结(一)

这篇讲的是作者在Android客户端与服务器端开发中的一些实战积累，尤其聚焦于“用户数据存储”和“通信协议选择”这两个常见却关键的问题。在通信协议部分，作者基于亲身体验，对比了四种常见方案。HTTP最简单但难以应对实时需求，尤其在移动网络下可能出现异常；WebSocket体验良好，能与现有HTTP服务器无缝结合；SocketIO虽然封装周全，但作者认为其过度兼容并不必要，且Python服务端在处理客户端断开连接时行为不符合预期；而原生Socket自定义协议灵活性最高，但开发难度也相应增大。关于用户数据存储，作者以Django Model为例，展示了基础用户表的设计，并特别分享了一个处理联合登录（如Facebook）的技巧：不破坏原有User表结构，而是新建关联表。他建议谨慎使用外键，为未来可能的数据迁移或拆分留出余地。作为系列文章的开篇，这篇总结没有泛泛而谈，而是通过具体的代码片段和协议优劣分析，为开发者提供了在项目初期做技术选型时的切实参考。

本机暂存

IT 开发者/ 2014-11-30 23:11:03 / 累计浏览 7,347

程序员装逼神器-TPP

厌倦了传统的PPT演示？这篇文章介绍了一个在终端里就能做演示的神器——TPP。它本质上是一款基于文本的演示工具，让你用简洁的命令语法，在终端中创建并展示幻灯片。文章详细介绍了如何通过一条 `sudo apt-get install tpp` 命令完成安装，并用具体例子展示了其输出效果。核心在于它独特的标记语言：你可以用 `-title` 定义标题，用 `-date today` 自动插入日期，甚至通过 `-beginoutput` 代码框直接展示代码片段。播放时，支持丰富的快捷键操作，如空格翻页、b键回退、l键刷新，交互体验流畅。除了默认的ncurses交互模式，TPP还支持自动播放（autoplay）、导出为LaTeX或纯文本文件，非常适合在终端环境或远程SSH会话中快速进行技术分享。作者通过详尽的语法清单（包括动画进入、文本样式、布局对齐等），展示了它如何将枯燥的文本变成结构清晰的演示文稿。对于喜欢极客范儿、追求在命令行中完成一切的开发者来说，这无疑是个提升效率又兼顾风格的小工具。

本机暂存

IT 后端/ 2014-11-28 23:31:06 / 累计浏览 3,203

通过FastCGI Cache实现服务降级

这篇讲的是如何在去掉CDN的PHP网站里，通过FastCGI Cache巧妙实现服务降级。背景是项目新增实时需求后架构稳定性下降，但完全重构不现实，因此需要一种尽可能透明的降级方案。核心思路是在Nginx层利用FastCGI Cache和error_page指令。正常流量时缓存被穿透，保持实时性；一旦后端返回500/502等错误，便通过重写触发降级逻辑，从缓存中提供陈旧内容，从而实现“断尾求生”。文章给出了可直接使用的通用版Nginx配置。更进一步，作者通过Lua脚本和共享字典实现了“定制版”：能自动统计单位时间内的错误次数，一旦超过阈值（如每分钟1000次），便全局自动激活缓存，无需人工干预。这种从“被动响应错误”到“主动判断系统健康并自动降级”的演进，是方案的亮点所在。

本机暂存

IT 数据库/ 2014-11-28 23:28:08 / 累计浏览 1,681

HBase在单Column和多Column情况下批量Put的性能对比分析

这篇讲的是HBase在不同数据模型下批量写入的性能差异。作者从一个实际现象出发：将数据存储在单个列（单列模式）与拆分成多个列（多列模式）时，批量Put的吞吐量存在巨大差距。测试数据显示，单列模式的TPS是多列模式的7倍以上，RPC调用次数也相差9倍。文章核心是从HBase的KeyValue内存模型入手，解释了这种差距的根本原因。在多列模式下，每一列都会携带大约50-60字节的元数据开销（如行键、列族、时间戳等），导致一行数据在客户端缓冲区中占用的内存远大于单列模式，进而触发更频繁的RPC提交，拉低了整体吞吐。作者通过代码计算put.heapSize()和KeyValue对象大小，验证了这一理论估算与测试结果高度吻合。文章最终给出实用建议：如果业务模型必须使用多列存储，在批量写入场景下，可以考虑适当调大客户端的write buffer，以缓解性能下降。

本机暂存

IT 算法/ 2014-11-28 23:24:04 / 累计浏览 8,173

一个故事告诉你比特币的原理及运作机制

这是一篇通过虚构故事来讲解比特币核心原理的科普文章。作者以“比特村”的货币演变史为线索，从以物易物、实物货币、符号货币到中央虚拟货币，逐步揭示出中心化记账的弊端——依赖个人信用、存在单点故障。在故事的关键转折点，一位名为“中本聪”的角色提出了比特币这套分布式解决方案。文章的重点不在于深入技术细节，而是生动地拆解了比特币系统的基础构件：将公开账本作为公共数据库，通过“保密印章”与“印章扫描器”的比喻形象解释了公钥加密的身份认证与数字签名机制。核心部分则聚焦于“矿工组织”如何通过共识工作（即“挖矿”）来共同维护和验证这个分布式账本，包括收集交易、填写账簿、解决哈希难题（比喻为“寻找幸运数字”）并竞争记账权。作者将复杂的区块链、工作量证明等概念，巧妙地转化为村民合作记账、防止作弊的日常场景。这种叙事方式清晰地勾勒出去中心化网络如何通过密码学与经济学激励，建立起无需信任第三方的价值传输体系，适合想快速建立比特币宏观认知的读者。

本机暂存

IT 移动开发/ 2014-11-28 23:22:31 / 累计浏览 2,990

APP设计中便捷的单手操作

这篇讲的是如何让APP的单手操作更顺手。作者从Steven Hoober对1333名用户的研究出发——49%的人习惯单手操作，其中拇指的可触及范围有限，且触控屏只识别按压的几何中心——引出了“视觉目标”与“触控目标”（热区）分离设计的核心原则。文章系统总结了四类提升单手效率的手势设计：一是利用左右滑动实现页面切换，但需权衡操作热区大小与误触风险（如iOS边缘返回与应用内任意位置返回）；二是通过手势在信息维度间切换（如日历的周/日切换、文章的概要/详情切换）；三是将内容相关操作（如点赞、删除）隐藏在对条目的滑动操作后，以节约屏幕空间；四是提炼高频功能并用简洁手势（如下拉、上划）快速呼出（如微博写作、亮度调节）。作者通过对比网易云阅读与iOS设置、新浪微博与Fuubo等实例，点明了不同设计方案对操作成本与学习门槛的影响。整体上，文章揭示了好的单手手势设计并非一味求简，而是需要在操作便捷性、场景契合度与防误触之间找到平衡点。

本机暂存

IT 算法/ 2014-11-28 23:21:14 / 累计浏览 3,128

基于用户尺度评价的人物角色分类方法与实践

这篇讲的是一种基于用户关注度的人物角色分类实践，以1688网站的供应商信息调研为具体案例。文章从“用户关注什么”这一核心目标出发，通过一份覆盖3032名有效用户的问卷，收集他们对17项供应商信息的5级关注度评分。接着，作者运用项目分析、信度检验和因子分析，将纷杂的信息项收敛为四个关键的评价维度：基本信息、客户满意度、供应能力和交易历史。基于这四个维度的因子得分，研究进一步对用户样本进行聚类，最终识别出三类典型角色：高度关注所有信息的“全面考察型”（占42.5%）、尤为看重满意度的“口碑驱动型”（占41.9%）以及关注度普遍较低的“轻度浏览型”（占15.7%）。这种划分直接揭示了不同用户群体在决策时的信息需求重心。文章的价值在于，它展示了一套从量化数据到设计洞察的完整流程。这些发现不仅为1688重构供应商信息页面的布局逻辑（如聚合关联信息）提供了依据，也说明了基于用户行为的分类如何辅助设计师识别核心用户，并理解其行为背后的动机，让设计决策更有据可依。

本机暂存

IT 后端/ 2014-11-28 23:18:12 / 累计浏览 4,478

再叙TIME_WAIT

这篇文章从一次“被反复问到”的经历出发，全面梳理了 TCP 协议中的 TIME_WAIT 状态。作者首先用几条简单的 Linux 命令，带我们直观感受繁忙服务器上动辄数万的 TIME_WAIT 连接。文章的核心在于解释了这种状态存在的“必要性”：它通过等待两倍的报文最大生存时间（MSL），确保双向关闭握手的数据包不会在不可靠的网络上引发混乱或干扰新连接。接着，文章深入对比了控制 TIME_WAIT 数量的几种主流内核参数调优方案。其中，`ip_conntrack` 虽能调整超时，但作者指出它带来的性能下降可能得不偿失。而广为流传的 `tcp_tw_recycle` 参数则隐藏着一个在 NAT 环境下可能导致连接失败的“时间戳陷阱”。相比之下，`tcp_tw_reuse` 被认为相对安全，但其关键限制在于仅对连接发起方（如作为客户端的 PHP）有效，且依赖时间戳递增机制。整体来看，这篇文章不是在简单罗列解决方案，而是深入剖析了问题的成因与各种方案的权衡。它提醒我们，那些试图强行缩短 TIME_WAIT 的“快捷方式”往往伴随风险，而理解其设计原理，才能为一次连接的优雅退场赋予合理的等待时间。

本机暂存

IT 安全/ 2014-11-28 23:14:05 / 累计浏览 2,916

云存储中的HTTP鉴权算法分析

云存储的安全高度依赖鉴权机制，传统的HTTP基本认证（Base64编码用户密码）因易被截获和反向解析，已无法满足云环境的安全需求。这篇文章对比了两大主流云平台——AWS S3与OpenStack Swift——为解决此问题所采取的不同鉴权路径。 AWS S3采用了基于请求签名的算法。其核心是每次请求时，客户端将请求元信息与私钥(SecretAccessKey)组合，通过SHA256哈希生成一个签名值随请求发送。服务端用同样方法计算签名并比对。即便请求被截获，攻击者也无法反推私钥，且签名与特定请求绑定并有时效性（15分钟），有效防范了密钥泄露和请求重放风险。相比之下，OpenStack Swift依赖Keystone服务发放的Token。客户端先用账号密码换取一个有效期Token，后续请求都需携带。服务端每次向Keystone验证Token的有效性。这种方式架构更集中，便于多服务共享鉴权。但缺点也明显：Token泄露风险较高，且每次请求都需额外验证，可能带来性能开销，历史上还出现过Token永久有效的Bug。两者的选择反映了不同的权衡：AWS S3在每次请求层面实现细粒度、高强度的安全；OpenStack Swift则追求服务治理的便捷与统一，但需在Token生命周期和验证效率上做好管控。

本机暂存

IT 后端/ 2014-11-28 23:13:09 / 累计浏览 4,055

全球通用头像Gravatar的介绍

一个头像走天下，这就是Gravatar全球通用头像服务想实现的。这篇文章清晰地拆解了这个服务对普通用户和开发者各自意味着什么。对于普通用户，核心是“一次上传，多站通用”。你只需用一个邮箱注册，上传并设置好头像的审核等级（G级最通用），之后在任何支持Gravatar的网站评论或互动时，系统会根据你留下的邮箱自动匹配并显示这个头像，省去了在每个网站重复上传的麻烦。对于开发者，文章深入到了实现细节。调用头像的核心在于一个基于用户邮箱的MD5哈希值。通过构造类似 `http://www.gravatar.com/avatar/哈希值` 的URL即可获取图像。更关键的是其灵活性：你可以通过URL参数指定头像尺寸、设置自定义的默认头像（比如你网站的Logo），甚至选择随机图案等内置的占位图，这让集成变得非常顺手。总的来说，Gravatar通过一个简单的邮箱关联机制，为用户解决了多站点身份形象统一的问题，也为开发者提供了一套轻量、可定制的头像API，是互联网身份管理一个巧妙的实践。

本机暂存

IT DevOps/ 2014-11-28 23:11:42 / 累计浏览 4,599

存储基础知识之——磁盘阵列原理及操作实战

这篇文章从磁盘阵列的物理结构讲起，重点拆解了Linux环境下逻辑卷管理（LVM）的核心概念与实操流程。作者先用通俗比喻厘清了LUN（逻辑单元号）在SCSI寻址体系中的扩展作用，随后将LVM的三个关键层次——物理卷（PV）、卷组（VG）、逻辑卷（LV）——逐一剖析。文章没有停留在理论定义，而是直接进入实战环节：从用fdisk修改分区格式为LVM专用的8e开始，依次演示了如何初始化PV、创建并激活VG、以及最终在VG上创建LV的完整命令链。其中还穿插了管理场景的处理，比如如何为现有VG扩容、安全移除PV等。对于需要灵活调配存储资源的运维或开发人员，这篇文章把从硬件到逻辑层的概念关联和操作路径理得比较清晰，尤其适合想理解LVM实际用途的读者。

本机暂存