IT
2014-11-19 23:30:42
/
累计浏览 1,867
这篇讲的是iMAG这个跨平台移动开发框架的入门上手。文章开宗明义，指出iMAG的核心优势在于“原生跨平台”——它采用XML加JavaScript的方式，将符合规范的代码解释成Android或iOS的本地原生控件来执行，因此拥有与原生应用一致的性能和用户体验。这一点将它明确区别于PhoneGap、JQuery Mobile这类Web技术封装的框架，更适合对性能要求较高的场景。
作者随后介绍了iMAG极为简洁的开发环境。开发者无需在本地搭建环境，只需在官网注册账号，安装手机客户端并使用在线工具，就能实时编辑XML并在手机上刷新查看效果，上手门槛极低。
文章通过一个“Hello World”示例，清晰展示了iMAG的XML结构。例如，使用封装页面，和<content>划分区域，而<list>控件则负责内容布局。这种结构会解释成各自平台的原生组件，比如Android上的TextView或iOS上的UILabel。文末还初步梳理了iMAG的控件体系，将其分为内容、表单和布局三类。总体来说，这篇文章为想快速构建高性能跨平台应用的前端或移动端开发者，提供了一个轻量且高效的新选项。</p>
<div class="br-actions" style="margin-top:8px;">
<button type="button"
class="br-button"
data-reader-favorite
data-type="it"
data-id="6957"
data-title="跨平台移动框架iMAG开发入门"
data-url="/it/article/6957"
data-mode="local"
aria-pressed="false">
<span data-favorite-label>☆ 稍后读</span>
</button>
</div>
</article>
<article class="br-card br-plain-card">
<div>
<div class="br-meta">
<span class="br-source-dot">IT</span>
<span>2014-11-19 23:07:06</span>
<span class="br-dot">/</span>
<span>累计浏览 3,453</span>
</div>
<h2 class="br-card-title"><a href="https://blogread.cn/it/article/6946">分布式消息系统尝试(rabbitmq, celery, redis)</a></h2>
<p class="br-summary">作者从统一游戏后台架构的需求出发，尝试使用Celery任务队列，并分别以RabbitMQ和Redis作为消息代理，来探索这套方案能否替代以前自研的C++ server通信模式。文章详细记录了在macOS下通过Homebrew安装RabbitMQ、启用其管理插件，并配置Redis和Celery的过程。
随后，作者通过一个简单的“加法”任务，对两种消息代理的性能进行了初步对比。在相同配置下，使用RabbitMQ时任务完成耗时约0.545秒，使用Redis时则约0.604秒。结果显示，在这个简单场景中两者的性能表现相近。
这篇文章为考虑引入任务队列的团队提供了一个具体的实践起点，展示了如何快速搭建并初步评估Celery+RabbitMQ或Celery+Redis这一组合。作者也指出，这只是初步测试，后续还需要对更多复杂场景和更高并发下的性能进行深入验证。</p>
<div class="br-actions" style="margin-top:8px;">
<button type="button"
class="br-button"
data-reader-favorite
data-type="it"
data-id="6946"
data-title="分布式消息系统尝试(rabbitmq, celery, redis)"
data-url="/it/article/6946"
data-mode="local"
aria-pressed="false">
<span data-favorite-label>☆ 稍后读</span>
</button>
</div>
<div class="br-thumb br-compact-thumb is-cached">
<img src="/upload/thumb/2026/05/b50aa6acc6bd36be3c7a87685bb9a4587e0ca42c.png" alt="" loading="lazy">
</div>
</article>
<article class="br-card br-plain-card br-plain-card--no-thumb">
<div>
<div class="br-meta">
<span class="br-source-dot">IT</span>
<span>2014-09-17 12:25:15</span>
<span class="br-dot">/</span>
<span>累计浏览 3,400</span>
</div>
<h2 class="br-card-title"><a href="https://blogread.cn/it/article/6909">规则引擎简介</a></h2>
<p class="br-summary">这篇讲的是如何用规则引擎将现实中的决策逻辑“外挂”到系统里。
文章从保险定价的生动例子切入：一辆红色运动型汽车，如果驾驶员是16-25岁男性，保费就增加20%。这种“如果……那么……”的逻辑，在路由表、权限控制等IT领域无处不在，但硬编码在程序中难以维护。规则引擎正是为了解耦这类业务规则而生。
它模拟了人类专家的推理过程，核心是规则库、事实库和推理引擎三大部件。推理引擎通过模式匹配器、议程和执行引擎来决定哪些规则被触发，以及按什么顺序执行。文中重点介绍了两种推理模式：由事实驱动、向前推导结论的正向推理，以及由目标驱动、向后寻找证据的反向推理。
文章还剖析了规则引擎的高效核心——RETE算法。这个由Charles Forgy发明的算法，通过将规则编译成推理网络，在运行时高效匹配事实与规则，避免了反复遍历的开销。
最终，规则引擎的价值在于让业务逻辑与技术实现分离。开发者不用在代码里写满复杂的if-else，规则可以像数据一样被管理和复用，为业务逻辑的快速迭代提供了坚实的技术底座。</p>
<div class="br-actions" style="margin-top:8px;">
<button type="button"
class="br-button"
data-reader-favorite
data-type="it"
data-id="6909"
data-title="规则引擎简介"
data-url="/it/article/6909"
data-mode="local"
aria-pressed="false">
<span data-favorite-label>☆ 稍后读</span>
</button>
</div>
</article>
<article class="br-card br-plain-card br-plain-card--no-thumb">
<div>
<div class="br-meta">
<span class="br-source-dot">IT</span>
<span>2014-08-13 12:34:57</span>
<span class="br-dot">/</span>
<span>累计浏览 5,077</span>
</div>
<h2 class="br-card-title"><a href="https://blogread.cn/it/article/6897">百度是如何使用hadoop的</a></h2>
<p class="br-summary">这篇文章讲的是百度如何将Hadoop深度应用于其海量中文搜索及数据处理场景。面对日志存储、网页挖掘、商业分析、在线反馈等复杂需求，百度不仅大规模部署了Hadoop（约700台机器，日均处理120TB数据），还针对实际运行中的效率与可靠性问题进行了系统性改造。
具体来看，百度在多个层面做了定制优化：在MapReduce策略上，通过限制作业并发、调整预测执行和基于节点内存调度来提升稳定性；对HDFS增强了权限控制与容错能力，比如让分区与节点解耦，避免单点故障影响全局。此外，他们还修改了推测执行（Speculative）策略，用速率倒数来更公平地触发备份任务，并引入资源控制机制，甚至修改Linux内核来限制进程内存使用。
文章也坦诚分享了百度在实践中遇到的痛点，包括MapReduce的I/O与排序效率、HDFS的随机访问延迟、内存管理压力以及作业调度精细化等问题，并针对如Streaming只能处理文本数据的局限，提出了自研的Bistreaming方案。这些细节揭示了在超大规模环境下，如何将开源框架“打磨”得更适合生产需求——不仅是使用，更是持续的调优与二次开发。</p>
<div class="br-actions" style="margin-top:8px;">
<button type="button"
class="br-button"
data-reader-favorite
data-type="it"
data-id="6897"
data-title="百度是如何使用hadoop的"
data-url="/it/article/6897"
data-mode="local"
aria-pressed="false">
<span data-favorite-label>☆ 稍后读</span>
</button>
</div>
</article>
<article class="br-card br-plain-card br-plain-card--no-thumb">
<div>
<div class="br-meta">
<span class="br-source-dot">IT</span>
<span>2014-07-28 12:43:31</span>
<span class="br-dot">/</span>
<span>累计浏览 2,551</span>
</div>
<h2 class="br-card-title"><a href="https://blogread.cn/it/article/6893">CAP 理论</a></h2>
<p class="br-summary">这篇技术文章深入剖析了CAP理论这个分布式系统的经典法则，指出很多人对其存在理解误区。作者从Brewer的原始猜想和Gilbert & Lynch的严谨证明出发，澄清了C、A、P三个属性在证明中的严格界定——尤其是将一致性(C)等同于数据库ACID中的原子性，这一点是理解后续讨论的关键。
文章梳理了CAP证明所依赖的强假设（如纯异步网络），并讨论了在现实中放松这些条件的可能。例如，放弃分区容错(P)意味着可扩展性受损，放弃可用性(A)则无法容忍服务中断，因此主流的分布式存储系统（如Cassandra、Dynamo）通常选择放宽一致性，转向最终一致性模型。
作者还对比了两种试图“挑战”CAP的思路：一种是通过引入版本控制和操作排队规则，让系统在不同时段分别满足CAP属性；另一种是通过数据模型重构（如仅追加数据、将读操作转化为查询），以更简单的方式拥抱最终一致性，从而规避CAP带来的复杂性。文章最终指出，CAP定理依然稳固，未来的关键或许在于如何通过巧妙设计绕过其严格限制的区域。</p>
<div class="br-actions" style="margin-top:8px;">
<button type="button"
class="br-button"
data-reader-favorite
data-type="it"
data-id="6893"
data-title="CAP 理论"
data-url="/it/article/6893"
data-mode="local"
aria-pressed="false">
<span data-favorite-label>☆ 稍后读</span>
</button>
</div>
</article>
<article class="br-card br-plain-card br-plain-card--no-thumb">
<div>
<div class="br-meta">
<span class="br-source-dot">IT</span>
<span>2014-05-27 22:56:54</span>
<span class="br-dot">/</span>
<span>累计浏览 2,733</span>
</div>
<h2 class="br-card-title"><a href="https://blogread.cn/it/article/6873">Dynamo和Cassandra海量存储基础</a></h2>
<p class="br-summary">这篇讲的是Dynamo和Cassandra这两个经典分布式存储系统，在核心设计哲学上的对比与剖析。文章从它们共享的基石概念入手，比如用W+R>N公式如何决定读写一致性级别，并用主备复制、Quorum机制等实例具体说明了N、W、R取值的影响。
真正的分歧点在于处理数据冲突的策略。Dynamo选择了更复杂的向量时钟，它像Git一样记录数据版本的来源，当检测到并行的、可能冲突的写入时，会保留所有版本交由应用层合并，适合能处理合并逻辑的场景。而Cassandra则采取了更粗暴的简化——时间戳方案，它不检测冲突，直接以最新时间戳的数据为准。这极大降低了复杂度，适用于大多数对冲突不敏感的场景。
文章还追溯了两者共同的基础——Gossip协议，并提及了它在去中心化通信中的优势与维持一致性的挑战。作者的对比最终导向了一个深刻的观点：在大多数写入冲突概率较低的场景下，这种最终一致性模型比强一致全局排序（如Paxos）更高效。两种不同的冲突解决路径，正体现了在工程化实现中对一致性权衡的不同哲学。</p>
<div class="br-actions" style="margin-top:8px;">
<button type="button"
class="br-button"
data-reader-favorite
data-type="it"
data-id="6873"
data-title="Dynamo和Cassandra海量存储基础"
data-url="/it/article/6873"
data-mode="local"
aria-pressed="false">
<span data-favorite-label>☆ 稍后读</span>
</button>
</div>
</article>
<article class="br-card br-plain-card br-plain-card--no-thumb">
<div>
<div class="br-meta">
<span class="br-source-dot">IT</span>
<span>2014-04-29 22:47:52</span>
<span class="br-dot">/</span>
<span>累计浏览 1,969</span>
</div>
<h2 class="br-card-title"><a href="https://blogread.cn/it/article/6858">Erlang公平调度的误解</a></h2>
<p class="br-summary">这篇讲的是Erlang引以为傲的“公平调度”哲学，在实际工程中可能并不像想象中那么完美。作者从Erlang虚拟机（BEAM）的时间片分配、抢占式调度说起，点明了它在云计算等场景下保障用户体验的初衷。
但文章的重点在于“祛魅”。作者指出，尽管Erlang的BIF、NIF等模块都在努力维护公平，但一些基础设计环节却可能无意中打破这种平衡。例如，消息队列的无保护单向队列结构，在极端负载下可能导致队列暴增和内存激增；而内存分配器在向系统申请内存时使用的锁，以及SMP架构下难以避免的锁竞争，都可能成为公平性的破坏者。文章最终总结，这些实现细节上的“坑”影响了Erlang在某些情况下的公平性表现，也解释了为何近期Erlang引入dirty scheduler等新机制来应对。
作者最后将视角拉高，提醒架构师需从上到下，在业务层面也进行“公平”设计，才能与系统哲学和谐统一。世界没有绝对公平，但理解其边界至关重要。</p>
<div class="br-actions" style="margin-top:8px;">
<button type="button"
class="br-button"
data-reader-favorite
data-type="it"
data-id="6858"
data-title="Erlang公平调度的误解"
data-url="/it/article/6858"
data-mode="local"
aria-pressed="false">
<span data-favorite-label>☆ 稍后读</span>
</button>
</div>
</article>
<article class="br-card br-plain-card br-plain-card--no-thumb">
<div>
<div class="br-meta">
<span class="br-source-dot">IT</span>
<span>2014-04-13 22:39:18</span>
<span class="br-dot">/</span>
<span>累计浏览 5,471</span>
</div>
<h2 class="br-card-title"><a href="https://blogread.cn/it/article/6844">写Java也得了解CPU缓存</a></h2>
<p class="br-summary">这篇讲的是，为什么像Java这样的高级语言开发者，也不能忽视底层的CPU缓存。作者从LMAX Disruptor框架和马丁关于“机械同理心”的博文出发，打破了“只有C/C++才需要懂CPU”的常规认知。
文章重点解析了CPU的三级缓存（L1/L2/L3）结构，并通过具体数据对比了各层级与CPU核心、内存之间的访问延迟差异，直观展现了数据局部性的重要性。作者还通过一段Java数组遍历代码的对比，生动演示了缓存行（Cache Line）的影响：符合内存访问顺序的循环，比按列访问的性能快了近70倍。这背后的原因，正是前者能高效利用单次缓存行加载的数据块，而后者则导致了大量不必要的缓存失效。
最终，文章梳理了导致缓存失效的三种常见情况（首次访问、冲突、缓存满），为优化程序性能指明了方向。这提醒我们，即使编写Java应用，理解硬件行为也能解锁显著的性能潜力。</p>
<div class="br-actions" style="margin-top:8px;">
<button type="button"
class="br-button"
data-reader-favorite
data-type="it"
data-id="6844"
data-title="写Java也得了解CPU缓存"
data-url="/it/article/6844"
data-mode="local"
aria-pressed="false">
<span data-favorite-label>☆ 稍后读</span>
</button>
</div>
</article>
<nav class="br-pagination" aria-label="pagination">
<ul class="pagination pagination-sm"><li class="page-item"><a class="page-link" href="/it/category/17">|<</a></li><li class="page-item"><a class="page-link" href="/it/category/17/2">2</a></li><li class="page-item"><a class="page-link" href="/it/category/17/3">3</a></li><li class="page-item"><a class="page-link" href="/it/category/17/4">4</a></li><li class="page-item"><a class="page-link" href="/it/category/17/5">5</a></li><li class="page-item active" aria-current="page"><span class="page-link">6</span></li><li class="page-item"><a class="page-link" href="/it/category/17/7">7</a></li><li class="page-item"><a class="page-link" href="/it/category/17/8">8</a></li><li class="page-item"><a class="page-link" href="/it/category/17/9">9</a></li><li class="page-item"><a class="page-link" href="/it/category/17/10">10</a></li><li class="page-item"><a class="page-link" href="/it/category/17/11">11</a></li><li class="page-item"><a class="page-link" href="/it/category/17/37">>|</a></li></ul>
</nav>
</section>
<aside class="br-stack br-sidebar" aria-label="IT sidebar">
<section class="br-side-card">
<h2>近 3 天十大热文</h2>
<ol class="br-rank-list">
<li><span class="br-rank">1</span><a href="https://blogread.cn/it/article/4237?f=hot3">浏览器的工作原理：新式网络浏览器幕后揭秘<small>近 3 天 87 浏览</small></a></li>
<li><span class="br-rank">2</span><a href="https://blogread.cn/it/article/6189?f=hot3">彻底屏蔽优酷广告<small>近 3 天 65 浏览</small></a></li>
<li><span class="br-rank">3</span><a href="https://blogread.cn/it/article/6194?f=hot3">linux下搜索find命令详解<small>近 3 天 60 浏览</small></a></li>
<li><span class="br-rank">4</span><a href="https://blogread.cn/it/article/8379?f=hot3">Postmortem: 关于 xzutil <small>近 3 天 58 浏览</small></a></li>
<li><span class="br-rank">5</span><a href="https://blogread.cn/it/article/5917?f=hot3">ZooKeeper管理员指南——部署与管理Z<small>近 3 天 57 浏览</small></a></li>
<li><span class="br-rank">6</span><a href="https://blogread.cn/it/article/7905?f=hot3">浅谈 WHR 全历史排名<small>近 3 天 56 浏览</small></a></li>
<li><span class="br-rank">7</span><a href="https://blogread.cn/it/article/4223?f=hot3">Google Megastore系统事务机制<small>近 3 天 54 浏览</small></a></li>
<li><span class="br-rank">8</span><a href="https://blogread.cn/it/article/4343?f=hot3">高性能EL――Fel探秘，兼谈EL<small>近 3 天 53 浏览</small></a></li>
<li><span class="br-rank">9</span><a href="https://blogread.cn/it/article/8382?f=hot3">让 AI 把我的 PHP 博客重写成 Go<small>近 3 天 43 浏览</small></a></li>
<li><span class="br-rank">10</span><a href="https://blogread.cn/it/article/1093?f=hot3">为什么GPL是更好的开源许可证?<small>近 3 天 39 浏览</small></a></li>
</ol>
</section>
<section class="br-side-card" style="padding:12px;text-align:center;">
<ins class="adsbygoogle"
style="display:inline-block;width:250px;height:250px"
data-ad-client="ca-pub-2206192680127944"
data-ad-slot="5430998082"></ins>
<script>(adsbygoogle = window.adsbygoogle || []).push({});</script>
</section>
</aside>
</main>
<footer class="br-shell" style="padding-top:12px;padding-bottom:20px;color:var(--br-muted);font-size:13px;">
<div style="text-align:center;line-height:1.9;">
© 2009 - 2026 by blogread.cn
·
微博：<a href="https://weibo.com/blogread" target="_blank" style="color:var(--br-accent)">@IT技术博客大学习</a>
·
<span class="news-footer-trust-links"><a href="/about.html">关于</a> · <a href="/contact.html">联系</a> · <a href="/privacy.html">隐私</a> · <a href="/disclaimer.html">内容来源声明</a></span>
·
<a href="https://beian.miit.gov.cn/" target="_blank">京ICP备15002552号-1</a>
</div>
</footer>
<!-- Bootstrap 5 bundle (含 Popper); 不再依赖 jQuery。 -->
<script src="/plugins/bootstrap-5.3.8/js/bootstrap.bundle.min.js"></script>
<script src="/assets/frontend-modern/reader-actions.js"></script>
</body>
</html>
