迁户口实录(深圳集体户到杭州个户)
这篇讲的是作者历时近三个月，将户口从深圳集体户迁至杭州个人户的全过程记录。整个办理从2011年12月19日开始，到2012年3月9日才最终完成，耗时远超预期。 问题主要出在户籍迁移流程缺乏足够的透明度。作者发现，由于对每次办理所需的具体材料准备不足，导致了多次往返和反复折腾。这其实也是许多人面对跨城迁户口时的共同痛点——环节多、要求细，官方指引往往不够详尽。 为了解决这个问题，作者完整记录了迁移中的每一步、所需文件以及遇到的具体障碍。这份“实录”的价值正在于它的细节性：它把一个看似简单的流程拆解成了具体可感的操作步骤，指出了哪些地方容易出错，哪些材料需要提前确认。对于同样面临户口迁移，特别是涉及集体户转个人户的同学来说，这份过来人的详细指南，或许能帮你省去许多不必要的奔波，让办理过程顺畅很多。
Java应用运维
这篇讲的是Java应用运维如何从零开始，一步步构建出自动化体系的过程。作者以亲身经历出发，描绘了运维工作随着应用规模增长而不断演进的典型路径。 文章首先从最基础的单机部署讲起：用Maven打包、SCP上传、执行启动脚本，再通过一个简单的JSP文件验证应用是否真正跑起来了。随着发布需求增多，脚本开始支持应用包和静态页面的快速更新与回滚。当应用从一台扩展到多台服务器时，运维工作又面临新挑战——不仅要搭建负载均衡环境，还要实现分批发布、灰度发布等策略。作者详细描述了如何通过脚本管理多台服务器，最终发展出一个包含应用信息登记、发布管理和权限控制的Web版运维系统。 这个演进过程的核心，是“用脚本解决重复劳动，用系统管理复杂度”。从最初的手工操作，到积累出环境部署、应用发布、负载均衡管理等一系列脚本，再到整合成支持多应用、多权限的运维平台，每一步都紧扣实际痛点。文章最后还提到，当运维规模继续扩大，还会遇到VLAN划分、虚拟化引入等更高级的挑战，为读者留下了进一步思考的空间。
记录碰到的HBase问题
这篇笔记记录了作者在实际生产环境中遇到的几个HBase典型问题。其中一个重点案例是关于Region热点：业务在写入时使用了时间戳作为RowKey前缀，导致大量写入集中在少数几个Region上，引起服务器负载不均。作者通过分析日志和监控数据定位到问题，最终调整了RowKey的设计策略，采用了加盐或反转等方法来散列写入流量，使集群负载恢复了均衡。另一个案例则涉及到了频繁的Major Compaction导致的I/O飙升，作者通过调整compaction策略和HDFS参数有效缓解了压力。 文章没有停留在现象描述，而是深入到了问题的根因分析和解决过程，包含了具体的操作步骤和参数调整思路。对于正在使用或即将使用HBase的开发者来说，这些来自一线的踩坑经验能帮助提前规避类似陷阱，或者在遇到问题时快速找到排查方向。
hbase运维
随着HBase在各大公司的广泛落地，运维成了绕不开的难题。这篇博文从作者亲身的运维实践出发，坦诚地分享了在管理HBase集群时遇到的典型挑战，以及总结出的应对方法。 文章没有空谈理论，而是直面那些让运维同学头疼的具体场景：比如如何处理RegionServer的频繁宕机与恢复、在业务高峰前预判并避免性能瓶颈，以及面对数据分布不均时的再平衡策略。作者深入分析了这些问题背后的常见根因，涉及配置调优、JVM管理、以及与Hadoop生态组件的资源竞争等多个层面。 在解决方案部分，文中详细描述了一套结合了监控告警、定期巡检和半自动化脚本的实战流程。特别值得一提的是，作者对ZooKeeper会话超时与HBase故障转移机制的协同处理给出了具体参数建议，这直接来源于他们多次线上故障的复盘经验。 文章的最后，作者也坦诚运维体系仍在完善中，并邀请同行交流补充。对于正在或即将承担HBase运维职责的工程师来说，这篇凝聚了一线经验的总结，能为排查问题和建立运维规范提供切实的参考。
HBase随机写以及随机读性能测试
这篇讲的是作者团队基于生产环境实战，借助自动化测试平台对HBase进行的系统性性能测试。文章聚焦于两种核心操作：纯粹的随机写入和随机读取，并直接分享了测试得出的性能数据。 不同于一般的理论介绍，作者从实际项目应用的经验出发，不仅报告了测试结果，还重点分享了经过他们调整和优化后的关键配置参数。这对于正在或计划使用HBase，并关注其高并发场景下性能表现的工程师来说，提供了直接的参考数据和调优方向。 文章的核心价值在于将生产环境的复杂需求转化为可复现的测试场景，用数据揭示了在不同参数设置下，HBase随机读写性能的差异。这些来自一线的实测结论，比纯理论更能指导实际的集群配置与优化工作。
记录帖：碰到的一些Java问题
这是一篇来自一线开发者的实战记录帖，汇集了几个典型的Java问题排查案例。文章以问题驱动，详细复现了从现象到根因的完整思考路径。 其中令人印象深刻的是集群启动失败的案例：相同的应用包和环境，部分节点却抛出NoClassDefFoundError。作者借助btrace追踪类加载器，最终发现是因为不同Linux节点上`File.listdir`返回的文件顺序（按inode号排序）存在差异，导致两个同名但内容不同的jar中的类被加载到了不同的地方，引发了冲突。这个发现揭示了一个隐蔽而常见的Java模块加载陷阱。 此外，文章还涵盖了GC频繁但不触发OOM的调优困境、堆外内存泄露（通常与Deflater未释放有关）的定位方法、压测时因第三方线程池配置不足导致的压力瓶颈，以及因未正确处理外部进程的标准输出/错误流而引发的应用死锁。 这些案例的价值在于，它们不仅仅给出了“怎么做”，更分享了“为什么这么想”和“过程中踩到了什么坑”，比如放弃`-XX:+TraceClassLoading`的原因，或是从网卡流量、线程状态逐步缩小排查范围的思路。对于遇到类似问题的开发者，这是一份可以直接参考的排查手册。
菜鸟谈HBase之写速度篇
这篇讲的是HBase写性能的实测与分析。作者从Facebook选择HBase作为消息存储系统的核心原因——高性能写——切入，通过实际的性能测试数据，带大家看看HBase在写入速度上的真实表现。 测试不仅揭示了HBase在不同场景下的写入吞吐量水平，更分享了团队在测试过程中碰到的若干实际问题。比如，如何设计合理的测试用例、在并发写入时可能遇到的瓶颈，以及数据最终对测试结果的影响。这些来自一线实践的细节，让性能数字变得更有说服力。 对于正在评估或已经使用HBase的开发者来说，这篇文章的价值在于它提供了超越理论值的实测参考，尤其是对测试方法的坦诚分享。它帮助读者更客观地理解HBase的写入能力边界，并在自己的架构决策中，能更准确地预估性能与定位问题。
构建高可用系统之故障篇
对于任何追求高可用的系统来说，故障都是一个绕不开的话题。完全杜绝故障往往不现实，核心思路是如何在故障发生时，将其对核心业务的影响降到最低，或快速恢复。 这篇文章正是围绕这一现实挑战展开。作者没有讨论理想架构，而是从**程序故障**这一具体切入点出发，并明确排除了人工操作失误的情形，聚焦于代码和运行时环境自身可能引发的问题。文章的核心观点很直接：面对不可避免的故障，我们的防御重点应放在“快速屏蔽”和“快速修复”上，这比单纯追求“绝对不出现故障”更为务实。 作为一篇经验总结型的文章，作者坦言内容主要源于其所在团队的实践，因此可能带有一定的视角局限性。但这恰恰让分享更显真诚，避免了空谈理论。文章旨在为读者提供一套应对程序级故障的实战思路，帮助你在故障突袭时，能有一套行之有效的行动指南，而非仅停留在概念层面。
心目中的容量规划平台
这篇讲的是作者心目中理想的容量规划平台应该是什么样子。文章从传统容量管理的痛点出发——资源利用率不透明、预测依赖经验且滞后、扩容决策往往被动且成本高。作者提出，一个优秀的平台核心目标是实现“从被动救火到主动规划”的转变。 为实现这一目标，平台被设计成几个核心模块：首先是自动化数据采集与治理，打通从物理机、容器到应用层的全链路指标；其次是基于历史数据与业务特性的智能预测引擎，能够输出未来多周期的容量趋势与风险预警；最后是可视化容量视图与模拟仿真，让决策者能直观评估不同业务增长模型下的资源水位与成本变化。 文章强调，这类平台的关键价值在于将容量从“成本项”转化为“可规划、可预测、可优化”的运维资产，使技术团队能提前布局，用数据和模型驱动基础设施的弹性伸缩，最终支撑业务平稳增长。这种设计思路为构建更健壮的容量管理体系提供了清晰的蓝图。
JRockit读书笔记I ― Java代码的高效执行
这篇读书笔记基于《Oracle JRockit: The Definitive Guide》一书展开，作者是该JVM的两位核心开发人员，其中Marcus Hirt更是JRockit Mission Control的负责人，其技术权威性毋庸置疑。 文章没有停留在泛泛的读后感，而是聚焦于书中最具价值的部分：它系统性地剖析了一个JVM的典型实现架构，并重点拆解了JRockit为追求高性能所做的关键优化决策及其背后的技术权衡。对于想深入理解Java代码执行效率根源的读者，这提供了难得的内部视角。即便对JVM底层不感兴趣，其中蕴含的“如何通过分析瓶颈来针对性优化”的工程思维，也极具启发性。 作者坦言书中知识体量巨大，因此计划以系列博客的形式持续分享阅读所得。这篇作为开篇，主要梳理了阅读初衷与全书脉络，为后续深入探讨具体的优化技术细节拉开了序幕。
服务框架演变过程
这篇讲的是一个厂内服务框架三年的演变与实战经验。 这个框架目前已部署超过2000个服务，日均执行次数稳定在120亿、峰值达150亿，规模相当可观。文章核心并非展示光鲜架构，而是作者坦诚分享这三年“摔过的跤”——由于早期经验不足，在框架广泛使用后不得不进行艰难的补救与重构。作者回顾了这个从零到大规模应用的全过程，总结了那些因规划不周而踩下的坑。 对于计划构建服务框架或推进服务化的团队，这篇最大的价值在于它的务实。它没有鼓吹一步到位的理想方案，而是强调在项目初期就应做好哪些关键铺垫，如何避免框架成型后因设计缺陷而被迫进行大改。这些来自大规模生产环境的第一手教训，能帮助读者在起步阶段就建立更稳健的基线。
BTrace使用简介
这篇讲的是如何用BTrace在不打扰生产环境的前提下，给运行中的Java应用做“实时体检”。作者从线上应用排障的痛点出发：当问题出现时，传统方式需要加日志、改代码、重新部署，这套流程不仅慢，遇到改不了的第三方包时更是束手无策。BTrace提供了一个更优雅的解法——它能让你动态地向运行中的JVM注入监控代码，按需查看方法的入参、返回值、执行耗时等关键运行细节，完全不用动原始代码，也不用重启服务。 文章接着进入了实战环节，介绍了BTrace脚本的核心元素：如何标注需要跟踪的方法（使用`@OnMethod`注解），以及怎样通过`@TLS`等注解在线程间安全地传递和存储数据。作者还展示了如何将捕获到的数据，比如方法执行时间，格式化输出到控制台，从而让隐藏的运行时行为变得可见。这种“打探针”式的诊断方式，特别适合那些难以复现的线上问题调查。 总的来说，这篇文章把BTrace定位成一个轻量而强大的线上诊断瑞士军刀，通过具体的注解用法示例，让读者能快速理解并上手这个工具，在系统不停机的情况下，精准地捕捉想要的信息。