IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

最新文章

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

IT 后端/ 2016-05-15 23:51:54 / 累计浏览 5,604

低延时直播应用

这篇讲的是直播技术里一个很实际的问题:如何实现低延时?作者从RTMP和HLS这两种主流协议入手,直接点明了核心差异——HLS延时通常在10秒以上,而RTMP则能实现秒级甚至更低的延时。 文章详细拆解了RTMP的“低延时”优势。在理想网络下,实测RTMP延时可以低至0.8秒左右,这对于互动直播、视频会议、监控等场景已经足够。但作者也坦诚地指出了RTMP的弱点,即基于TCP会导致“累积延迟”,在网络波动时缓冲区会像滚雪球一样增大。文中还深入探讨了一个关键技术点——GOP(关键帧间隔)缓存的影响:为了快速启动播放,服务器通常会缓存上一个GOP,这直接增加了延时;而通过调整编码器GOP长度或使用SRS关闭GOP缓存,则可以在这两者间进行权衡。 更难得的是,文章没有停留在理论对比,而是提供了具体的延时测量方法(如使用手机秒表),并分析了影响延时的多个实际因素,比如服务器性能、客户端缓冲区设置(如flash的bufferTime设为10秒则延时至少10秒)、以及不同流媒体服务器实现(如Nginx-Rtmp)的差异。这些细节让结论非常扎实,对需要搭建或优化直播系统的工程师来说,是一份清晰的实践参考。

本机暂存
IT 后端/ 2016-05-15 23:49:38 / 累计浏览 1,571

代理服务和过载保护

这篇讲的是如何在skynet框架中,通过前置代理服务来解决热点服务的过载问题。作者指出,服务过载是并发环境下最常见也最棘手的问题之一,而代理服务能在不增加功能服务复杂度的前提下,提供有效的保护。 核心方案是为热点服务增加一个代理层。这个代理可以智能地调度请求:当检测到某服务请求过于频繁时,会优先处理其他请求以保证公平;同时能自动丢弃那些来自已退出服务的无效请求。更重要的是,它能感知后端功能服务的负载情况,当服务过忙时缓存新请求。这带来一个实际好处:线上排障时,通过调试控制台直接发送的控制指令能绕过拥堵的请求队列,得到更快的响应。 文章不仅给出了概念,还深入了实现细节。作者展示了如何利用 `skynet.forward_type` 编写高效的代理服务,通过直接传递消息指针来避免不必要的内存拷贝。此外,还介绍了两种关键的运维能力:如何通过 `debug ping` 协议快速检测目标服务的响应延迟以判断是否过载,以及如何利用 `debug link` 指令来感知服务退出,从而清理无效请求。整套方案从架构设计到代码实现,为处理并发环境下的服务保护问题提供了清晰的思路。

本机暂存
IT 数据库/ 2016-05-15 23:48:52 / 累计浏览 2,507

mysql,redis数据备份方案

这篇讲的是,一家公司在阿里云上自建MySQL和Redis存储时,如何从一套简陋的备份方案,逐步迭代出相对可靠的数据保障策略的实践。 起初,团队的备份方案是每天一次冷备加Redis的RDB自动保存,简单但隐患重重:MySQL的dump操作会引发游戏卡顿,冷备间隔过长导致恢复数据太旧,Redis缺乏热备风险大。 针对这些痛点,他们首先优化了MySQL方案:搭建主从同步实现热备,并将冷备任务转移到从机上每十分钟执行一次,再同步至OSS,避免了主机性能受损。接着处理Redis备份,最初考虑效仿MySQL做主从热备,但评估后发现,如果主机宕机重启,其RDB可能会覆盖从机数据;而从机重建同步又会触发主机大规模bgsave,可能导致内存飙升。最终,他们选择了一个务实的方案:将RDB文件通过SSH传输到另一台独立机器上进行冷备,从而规避了本地磁盘IO竞争导致MySQL变慢的核心问题。 整个过程印证了作者开头的观点:很多事的推进,取决于“时”与“势”。而备份方案的完善,正是在服务器故障的“势”到来之前,团队早已开始思考和储备的结果。

本机暂存
IT 前端/ 2016-05-12 12:55:11 / 累计浏览 1,577

移动web开发调试工具AlloyLever介绍

这篇介绍的是AlloyLever,一个轻量但功能强大的移动端Web调试工具。它直接解决了移动调试的三大高频痛点:查看日志(Log)、捕获脚本错误(Error)、监控网络请求(AJAX)。 与开发者需要连接电脑调试不同,AlloyLever通过在页面中注入一个JS文件,就能提供一个类似桌面浏览器DevTools的浮动面板。它巧妙地通过重写`console`方法和`XMLHttpRequest`对象,来拦截并记录所有的日志输出、JS错误、资源加载失败以及XHR请求的完整生命周期。同时,它也能展示Cookie、LocalStorage和页面性能时间线。 这种“注入即用”的设计,极大地降低了移动端调试的门槛,特别适合在真机上快速定位问题。文章还清晰地拆解了其实现原理,比如如何通过回调检查AJAX状态来捕获响应数据,可读性很高。对于常做移动端开发的团队来说,这是一个能显著提升排错效率的实用工具。文章末尾也提到了微信团队的vConsole,方便读者对比选择。

本机暂存
IT 移动开发/ 2016-05-12 12:52:32 / 累计浏览 2,848

一个 GUI 系统的组成部分

这篇文章从作者开发 iOS 上的 XML+CSS UI 布局框架 CocoaUI 的切身实践出发,探讨了构建一个现代 GUI 系统所需的基石。作者首先犀利地指出了 iOS 与 Android 在界面体验上的差距,认为其根源很大程度在于底层的软件技术,尤其是字体渲染。他推崇苹果在高分辨率屏幕上锐利的渲染技术,并直言某些虚化技术带来的粗糙感。 随后,文章系统性地梳理了自建一个 GUI 系统至少需要的六大核心模块:从最基础的 Core Text(字体渲染)和 Core Graphics(2D 图形引擎),到赋予界面生命力的 Core Animation(动画)和 Event Handling(事件处理),再到支撑智能设备的 Core Audio/Video(多媒体)与 WebKit(浏览器引擎)。作者认为,字体技术的长期积累是重中之重。 最后,作者以自己的 CocoaUI 框架为例,介绍了如何利用类 Web 的 HTML+CSS 技术进行界面布局,将界面描述与逻辑编程分离,避免了用 XML 进行“编程”的误区。整篇文章是作者对 GUI 技术栈的深入思考与经验总结。

本机暂存
IT 安全/ 2016-05-12 12:51:53 / 累计浏览 2,721

浅析Windows的访问权限检查机制

这篇深入剖析了Windows操作系统中访问权限检查的核心模型。作者从被保护的“对象”与发起访问的“主体”(进程/线程及其令牌)出发,清晰地勾勒出权限检查的基本逻辑:用主体的有效令牌去匹配客体的安全描述符。 文章揭示了访问权限检查是一个多维度、层层递进的体系。其中,对DACL(自主访问控制表)的检查是基石,文章特别指出DACL中访问控制项(ACE)的顺序至关重要——一个显式拒绝的条目如果排在显式允许条目之后,其效力将被完全覆盖。通过API添加ACE不受顺序限制,但通过GUI操作时,系统为确保拒绝策略的有效性,会固定将拒绝条目置于允许条目之前。 除了DACL,检查还涉及特权(如SeDebugPrivilege)、完整性级别(IL)、受限令牌以及从Win8引入的AppContainer能力检查等多个维度,这些机制共同构建了Windows的安全沙箱。文章最后展示了TOKEN结构体的具体字段,让读者得以窥见权限检查背后最核心的数据结构。整篇文章从抽象模型到具体实现,展现了Windows安全机制随时代演进的完整脉络。

本机暂存
IT 算法/ 2016-05-12 12:50:58 / 累计浏览 2,794

有追求优秀之心的程序员

这篇文章从一条引发热议的微博出发,探讨了当下程序员群体中基础能力参差不齐的现象。作者指出,行业门槛降低使得许多仅能“完成任务”的个体进入,但这并不应成为放弃专业追求的理由。 文章的核心观点是,区分“普通”与“优秀”程序员的关键,在于是否具备“追求优秀之心”。作者以面试者连冒泡排序都不会写为例,强调基础逻辑思维的重要性。优秀的程序员不仅能实现功能,更擅长进行业务抽象,通过合理的技术选型确保系统在苛刻条件下依然准确可靠。 最后,文章鼓励那些理解程序内在、能进行逻辑抽象的程序员,应当认识到自己的稀缺性与价值,相信自己“出身高贵”,理应获得更好的回报。整篇文章在技术讨论中,传递了关于职业尊严与自我期许的思考。

本机暂存
IT DevOps/ 2016-05-05 22:58:05 / 累计浏览 3,618

Linux内存中的Cache真的能被回收么?

这篇讲的是Linux系统中一个经典但常被误解的问题:那些被buffer和cache占用的内存,到底能不能在需要时被释放。文章从`free`命令的输出切入,指出了三种不同层次的理解,并重点剖析了第二种——即很多人认为buffer/cache内存“随时可释放”的认知其实并不完全准确。 作者清晰解释了page cache和buffer cache的核心区别:前者主要用于缓存文件读写,后者用于块设备I/O缓存。Linux内核确实会在内存压力大时回收这些缓存,但这个过程并非没有代价——回收前必须确保缓存数据与磁盘文件一致,往往会导致瞬间的IO飙升。 文章的真正价值在于通过一个具体的tmpfs实验揭示了回收的边界。当把大量数据存入基于内存的tmpfs文件系统时,这部分内存会体现在`cached`指标里,`free`命令也提示有很多“可用”内存。然而,当尝试手动执行`echo 3 > /proc/sys/vm/drop_caches`进行回收时,这部分内存却无法被释放,因为它本质就是系统分配给tmpfs的物理内存,不属于可回收的缓存范畴。 因此,结论很明确:并非所有在`free`命令中显示为“cached”的内存都能被回收。像tmpfs这类“内存就是存储”的场景,占用的空间是“实实在在”的已使用内存,这与加速文件访问的磁盘缓存有本质区别。理解这一点,对于准确评估系统内存压力至关重要。

本机暂存
IT 后端/ 2016-05-05 22:56:44 / 累计浏览 3,656

Maven依赖机制简介

这篇讲的是Maven作为构建工具,其核心且强大的依赖管理机制。作者从依赖如何被自动传递和解析讲起,详细拆解了传递性依赖背后的关键规则:当出现版本冲突时,Maven遵循“短路径优先”,在路径长度一致时则看POM声明顺序(第一声明原则)。 文章清晰地对比了六种不同的依赖范围(如compile、provided、runtime等),用表格明确了它们在编译、测试、运行时对classpath的影响以及如何相互传递,这是实际开发中配置依赖必须厘清的差异。 此外,文中还介绍了通过在父POM中集中管理依赖版本与排除项的方法,这对于维护大型多模块项目、保持依赖一致性非常实用。整体而言,文章从基础概念到复杂场景,系统梳理了Maven处理依赖的逻辑,能帮助开发者更好地掌控项目构建。

本机暂存
IT 后端/ 2016-05-05 22:55:23 / 累计浏览 1,609

过去六年在小米搞(wa)错(keng)的几个技术细节

这篇来自小米早期技术团队的复盘文章,诚实地回顾了在搭建米聊及后续服务时,因经验不足和快速迭代而埋下的六个关键技术“坑”。它并非聚焦单一故障,而是从架构选型和工程实践的层面,剖析了那些当时看似合理、事后却带来长期困扰的决策。 文章逐一拆解了具体问题:比如早期使用 Nginx 代理 Java 服务时缺乏平滑发布机制,导致上线必然有损;监控体系只关注单个模块指标,无法有效定位跨模块交互的问题;以及在移动端网络环境下,选择 HTTP 协议框架在当时可能存在更优的 TCP 方案。在语言与存储选型上,作者反思了在缺乏深度专家的情况下选择 Java 带来的稳定性挑战,以及过度依赖 MySQL 为后期多机房容灾设下了障碍。最后,对 RabbitMQ 的泛滥使用提出了警示,指出了服务间调用关系不透明带来的运维灾难。 作者的核心观点在于:一些技术细节上的“将就”,会在业务规模增长后演变为系统性的瓶颈。这些来自实战的教训——无论是关于发布流程、监控哲学、通信协议还是存储设计——都揭示了前瞻性架构思考与技术深度对于构建大规模、可持续系统的重要性。

本机暂存
IT 后端/ 2016-05-05 22:54:10 / 累计浏览 3,387

java enum枚举类型用法小结

这篇讲的是Java枚举(enum)的核心特性与实用技巧。文章从枚举的本质出发,指出它实际上是一种特殊的final类,继承自`java.lang.Enum`,所有枚举值都是`public static final`的常量。 作者通过示例代码,拆解了枚举的关键设计:其构造器必须私有,以确保外部无法实例化,这符合枚举作为常量集的初衷。接着,文章梳理了枚举类继承自Enum的常用方法,例如`ordinal()`用于获取声明顺序,`values()`能返回所有枚举值的数组,`valueOf()`则可根据字符串名称反向获取实例。 除了基础API,文章还着重展示了枚举的几种实战用法:用作类型安全的常量定义、在switch语句中提升代码可读性,以及如何向枚举中添加自定义字段和方法,使其承载更丰富的信息。这些内容覆盖了从入门到进阶的常见场景,能帮助开发者理解枚举不仅仅是一组常量,更是一个功能完备、封装良好的类型。

本机暂存
IT 前端/ 2016-05-05 22:53:17 / 累计浏览 2,257

zepto/jQuery、AngularJS、React、Nuclear的演化

这篇文章梳理了前端开发中处理DOM交互的技术演化路径。从最初无框架时代直接在DOM元素上声明事件,导致全局变量污染和脚本执行时序问题开始,讲到开发者通过命名空间、工具函数库逐步封装DOM查询与事件绑定。接着展示了jQuery/zepto如何通过统一API将这些操作整合,极大简化了开发流程,但早期版本仍存在脚本加载期间交互失效的体验问题。文章通过代码示例直观对比了各阶段方案的痛点与改进,核心脉络在于:前端框架的演化始终围绕着解决“如何更优雅、更健壮地建立人机交互”这一刚需,从补丁式封装走向系统化的抽象层设计。

本机暂存
IT 前端/ 2016-05-05 22:44:05 / 累计浏览 2,073

元素选择器 - Mini Query

这篇讲的是如何用寥寥几行代码实现一个简单但功能完整的元素选择器,并且巧妙地兼容了IE8以下的老式浏览器。 作者从一个实际的前端兼容性需求出发:虽然现代浏览器已经原生支持 querySelector 和 querySelectorAll,但在需要照顾低版本IE的项目中,开发者往往需要 hack。文章提出的核心方案原理清晰且富有巧思——通过动态创建一条CSS规则并应用到目标元素上,给它们打上一个临时标记(比如“Barret:Lee”这个属性)。接着,只需遍历页面所有元素(document.all),检查哪些元素“染上”了这个标记,就能将它们收集起来。完成任务后,再移除这条临时规则,保持页面清洁。 文章提供了完整的实现代码,其中可以看到对 IE8 等环境的针对性处理,例如修复 `querySelectorAll` 返回值的兼容性问题。这种利用CSS Rule作为“探针”来定位元素的方法,避免了复杂的DOM遍历,实现轻量而有效,对于需要处理历史遗留项目的开发者来说,是一个值得了解的小技巧。

本机暂存
IT 后端/ 2016-05-05 22:43:15 / 累计浏览 1,699

记录一种工作流心跳机制的设计

这篇讲的是在基于Amazon SWF的工作流中,如何设计一个可靠的心跳机制来维持长时间任务的存活。作者从实际开发踩坑出发,分享了应对SWF 5分钟超时限制的解决方案。 核心方案是采用两个双端队列(main queue和backup queue)来统一管理所有需要心跳的任务。每秒从主队列取出一个任务发送心跳,完成后放入备份队列;每两分钟(一个周期)再将备份队列的任务批量移回主队列,开始新一轮循环。这个设计巧妙地解决了并发下的任务状态跟踪问题,比单队列加计数器的方案更简单高效。 文章深入探讨了几个关键设计考量:心跳频率并非越快越好,需要在及时性和避免服务端限流之间做权衡;周期长度(如120秒)的设置要能覆盖超时时间并提供重试余地。更重要的是,作者详细剖析了心跳失败时的分级处理策略:对于资源已取消等常规异常直接移除任务;对于限流错误立即重试;对于其他未知异常则放入当前周期队尾重试并计数,避免影响其他任务。 最后,通过一个EMR集群因心跳超时和检查逻辑缺陷被误回收的实例,说明了在真实分布式环境中,看似简单的心跳机制与任务超时、资源监控等环节环环相扣,设计时需要全局考量,用绝对时间而非操作次数来判断状态才更可靠。

本机暂存
IT 前端/ 2016-05-05 22:41:53 / 累计浏览 1,506

JavaScript 代码执行效率对比工具

这篇文章介绍了一个用于对比JavaScript代码执行效率的轻量级工具。作者从小程序和大型工程对性能需求的不同出发,梳理了几种常见的性能测试方案,包括使用在线平台 jsperf.com、利用 `console.time` 计时以及自己编写计时器。 为了更直观地对比不同代码片段的性能差异,作者开发了这个名为 Performance 的工具。其核心设计思路是在设定的时间内(默认1000ms)循环执行指定的代码,并基于执行结果计算出一个相对的效率百分比。其中效率最高的代码会被标记为100%,其余代码则显示为相对的性能百分比,从而让性能高低一目了然。 文章提供了工具的在线演示页面和 GitHub 仓库地址,方便读者快速上手体验。对于正在编写框架或库、需要精细优化关键代码路径的前端开发者来说,这个工具提供了一种便捷的本地化性能评测与对比方式。

本机暂存
IT 前端/ 2016-05-05 22:39:15 / 累计浏览 1,501

用javascript比较语义化版本号

在移动端混合开发场景中,根据APP或其内置浏览器的版本号来执行不同业务逻辑,是一个常见需求。这篇文章聚焦于如何用JavaScript去精确比较语义化版本号(如`6.1.5`这样的格式)。 作者首先澄清了版本号的标准格式(主版本号.子版本号.修正版本号),随后提供了一个清晰的JavaScript函数实现。这个函数的核心思路是将版本字符串按`.`拆分后,逐段比较数字大小,从而判断当前版本与目标版本的高低。文章通过几个简洁的示例,展示了具体的调用方式和结果。 值得注意的是,作者坦诚该方法实现较为基础,只支持完整的版本号串比较,无法单独比较主版本或子版本。文末还补充了一个实用范例:如何从微信浏览器的UA中提取版本号并进行条件判断,这为实际项目中的落地提供了直接参考。整体来看,文章从实际问题切入,给出了一个轻量、可用的解决方案。

本机暂存
IT 后端/ 2016-05-05 22:36:20 / 累计浏览 2,329

《Effective java》—–读书笔记

读完《Effective Java》后,作者结合自己的面试反思与年度学习计划,写下这篇笔记,摘录并梳理了书中多条核心原则。笔记从创建对象讲起,强调了静态工厂方法的优势、避免创建不必要对象以及如何通过私有构造器或枚举强化单例。接着,重点讨论了类与接口设计:最小化可访问性、为不可变性努力、优先使用组合而非继承、以及如何用接口定义类型和用骨架实现类弥补抽象类的不足。 在方法层面,笔记总结了慎用重载和可变参数、返回零长度数组而非null等实用建议。通用编程部分则归纳了最小化局部变量作用域、优先使用for-each循环和基本类型等性能与可读性并重的技巧。最后,笔记也提到了异常处理的原则——异常应只用于异常情况。 这些笔记摘录不仅保留了原著的精华论点,还结合了博主自己的理解,如通过WeakHashMap管理缓存、继承判断的“is-a”原则等,将“四大圣经”之一的实践智慧转化为开发者可直接参考的要点清单。

本机暂存
IT 安全/ 2016-05-05 13:21:43 / 累计浏览 2,488

iptables 看门狗

这篇讲的是如何为容易“开门忘关”的服务器防火墙设置一个自动看门狗。作者从近期因Redis配置不当导致服务器被黑的常见事件切入,指出核心风险往往在于人为疏忽:为了方便临时关闭了iptables,事后却忘记重新开启,给攻击者敞开了大门。 为了解决这个问题,文章提供了一个简洁的Shell脚本方案。这个脚本扮演了“看门狗”的角色:它会定期检查防火墙状态,一旦发现防火墙是关闭的,并且当前没有用户登录服务器(即“家里没人”),就会自动执行启动命令,将防火墙重新打开。 整个方案的核心思想简单而实用——用自动化弥补人为操作的漏洞。脚本通过检查`iptables`服务状态和`who`命令的输出行数这两个关键条件,实现了精准的自动化干预。它不依赖复杂的监控系统,仅用几行命令就构建了一个基础的安全保障机制,特别适合运维人员快速部署在需要长时间开放调试、又担心忘记恢复防火墙的服务器上。

本机暂存
IT 移动开发/ 2016-05-05 13:08:17 / 累计浏览 2,498

Android应用内存泄露分析、改善经验总结

这篇讲的是作者如何系统性地分析和改善Android应用的内存泄漏问题。他以实际优化案例开头,展示了将应用退出后内存占用从100多M降至20M以内的显著效果,并成功定位了InputMethodManager和MTK WebView中的具体泄漏点。 作者分享了一套行之有效的方法论:首先遵循“数据说话”和“持续改善”的原则。具体步骤上,建议优先用Android Studio的静态分析解决常见泄漏,比如Handler、未关闭的IO资源和Context使用不当等问题。对于更隐蔽的泄漏,则需要借助Leakcanary或adb命令在程序运行后进行监控,并使用MAT工具对内存快照进行深入分析。文章还详细说明了如何验证改善效果,形成闭环。 整篇文章就像一份手把手的排障指南,从原则、具体操作到验证,流程清晰。特别是对使用MAT时的关键注意事项(如关注Retained Size、排除软弱引用)的总结,对于实际解决问题很有参考价值。

本机暂存
IT 数据库/ 2016-05-05 13:07:08 / 累计浏览 2,193

MySQL复制线程长时间Opening tables

这篇讲的是一个MySQL主从复制中,slave实例的SQL线程长时间卡在“Opening tables”状态,导致复制延迟超过16小时的实际案例。 作者从现象出发,先排除了table cache过小的常见猜测,通过检查slave status、系统负载和磁盘IO,均未发现明显异常。线索最终指向了MySQL的错误日志,其中出现了大量关于“performance_schema”表结构错误的提示。 问题的根源在于跨版本复制:master是MySQL 5.5,而slave是5.6。从5.5到5.6,performance_schema的内部表定义发生了变化。当使用xtrabackup搭建新slave后,旧的5.5版本元数据被带入,导致5.6版本的slave在尝试打开并初始化这些系统表时,因结构不符而陷入困境。 解决方法明确:在slave实例上执行`mysql_upgrade`命令,更新所有系统表到正确的版本。这个案例提醒我们,在MySQL版本升级或跨版本搭建复制环境时,系统表的兼容性是一个需要特别注意的潜在风险点。

本机暂存