C语言编程中常用的三种循环为for（；；），while 和 do-while。
1. for循环
for循环形式： for（表达式1；表达式2；表达式3）
流程图：
图1 for循环流程图
2. while循环
while循环形式：
while（判断条件）
{
执行语句；
}
流程图：
图2 while循环流程图
3. do-while循环
do-while循环形式：
do
{
执行语句；
}while（条件判断）
do-while循环流程图：
图3 do-while循环流程图
作者：绿茶叶
出处：http://www.cnblogs.com/greenteaone/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。… 阅读全文
天云趋势在2012年下半年开始为某大型国有银行的历史交易数据备份及查询提供基于Hadoop的技术解决方案，由于行业的特殊性，客户对服务的可 用性有着非常高的要求，而HDFS长久以来都被单点故障的问题所困扰，直到Apache Hadoop在2012年5月发布了2.0的alpha版本，其中MRv2还很不成熟，可HDFS的新功能已经基本可用，尤其是其中的的High Availability(以下简称HA)和Federation。Cloudera也于7月制作了CDH4.0.1，包含了Hadoop 2.0的诸多新功能和组件，于是我们就基于CDH4.0.1进行了HA和Federation的测试。
此工作由我和同事张军、钱兴会共同完成。
1. 单点故障
在Hadoop 2.0之前，也有若干技术试图解决单点故障的问题，我们在这里做个简短的总结
2. 集群容量和集群性能
单NN的架构使得HDFS在集群扩展性和性能上都有潜在的问题，当集群大到一定程度后，NN进程使用的内存可能会达到上百G，常用的估算公式为1G 对应1百万个块，按缺省块大小计算的话，大概是64T (这个估算比例是有比较大的富裕的，其实，即使是每个文件只有一个块，所有元数据信息也不会有1KB/block)。同时，所有的元数据信息的读取和操作 都需要与NN进行通信，譬如客户端的addBlock、getBlockLocations，还有DataNode的blockRecieved、 sendHeartbeat、blockReport，在集群规模变大后，NN成为了性能的瓶颈。Hadoop 2.0里的HDFS Federation就是为了解决这两个问题而开发的。
SBT是Simple Build Tool的简称，如果读者使用过Maven，那么可以简单将 SBT 看做是Scala世界的Maven，虽然二者各有优劣，但完成的工作基本是类似的。虽然 Maven同样可以管理Scala项目的依赖并进行构建，但SBT的某些特性却让人如此着迷
相关信息参见： http://www.scala-sbt.org/release/tutorial/zh-cn/index.html 里面有详细的介绍， 本文是从网络搜集的一些介绍供参考。
比如:
使用Scala作为DSL来定义build文件（one language rules them all ） ;
通过触发执行(trigger execution) 特性支持持续的编译与测试；
增量编译；^[SBT的增量编译支持因为如此优秀,已经剥离为Zinc,可被Eclipse,Maven,Gradle 等使用 ]
可以混合构建Java和Scala项目；
并行的任务执行；
可以重用Maven或者ivy的repository进行依赖管理；
等等这些，都是SBT得以在Scala的世界里广受欢迎的印记。
SBT的发展可以分为两个阶段，即SBT_0.7.x时代以及SBT_0.10.x以后的时代。
目前来讲,SBT_0.7.x已经很少使用,大部分公司和项目都已经迁移到0.10.x以后的版本上来，最新的是0.12版本。0.10.x之后的版本build定义采用了新的Settings系统，与最初0.7.x版本采用纯Scala代码来定义build文件大相径庭，虽然笔者在迁移之前很抵触（因为0.7.x中采用Scala定义build文件的做法可以体现很好的统一性），但还是升级并接纳了0.10.x以后的版本，并且也逐渐意识到， 虽然新的版本初看起来很复杂， 但一旦了解了其设计和实现的哲学跟思路,就会明白这种设计可以更便捷的定义build 文件。而且可选的build文件方式也同样运行采用Scala代码来定义，即并未放弃统一性的思想,以上是 SBT 的简单介绍.
build.sbt非常简单，它隐藏了sbt实际是如何工作的。sbt构建是用Scala代码定义的。这些代码自身需要建立。还有比sbt更好的方式吗？
project文件夹是你项目中的另一个子项目，它知道如何构建你的项目。子项目（理论上）可以可以做任何其他项目能做的事情。你的构建定义就是一个sbt项目。
… 阅读全文来源：http://www.blogjava.net/paulwong/archive/2013/10/31/405860.html
Flume是一个分布式、可靠、和高可用的海量日志聚合的系统，支持在系统中定制各类数据发送方，用于收集数据；同时，Flume提供对数据进行简单处理，并写到各种数据接受方（可定制）的能力。
(1) 可靠性
当节点出现故障时，日志能够被传送到其他节点上而不会丢失。Flume提供了三种级别的可靠性保障，从强到弱依次分别为：end-to-end（收到数据agent首先将event写到磁盘上，当数据传送成功后，再删除；如果数据发送失败，可以重新发送。），Store on failure（这也是scribe采用的策略，当数据接收方crash时，将数据写到本地，待恢复后，继续发送），Best effort（数据发送到接收方后，不会进行确认）。
(2) 可扩展性
Flume采用了三层架构，分别为agent，collector和storage，每一层均可以水平扩展。其中，所有agent和collector由master统一管理，这使得系统容易监控和维护，且master允许有多个（使用ZooKeeper进行管理和负载均衡），这就避免了单点故障问题。
(3) 可管理性
所有agent和colletor由master统一管理， 这使得系统便于维护。多master情况，Flume利用ZooKeeper和gossip，保证动态配置数据的一致性。用户可以在master上查看各 个数据源或者数据流执行情况，且可以对各个数据源配置和动态加载。Flume提供了web 和shell script command两种形式对数据流进行管理。
(4) 功能可扩展性
用户可以根据需要添加自己的agent，collector或者storage。此外，Flume自带了很多组件，包括各种agent（file， syslog等），collector和storage（file，HDFS等）。
flume的逻辑架构：
正如前面提到的，Flume采用了分层架构：分别为agent，collector和storage。其中，agent和collector均由两部分组成：source和sink，source是数据来源，sink是数据去向。
Flume使用两个组件：Master和Node，Node根据在Master shell或web中动态配置，决定其是作为Agent还是Collector。
agent的作用是将数据源的数据发送给collector。
目前我们使用的流程图制作软件大体有RFFLOW、FLOW CHARTING、VISIO三种，可是它们的体积和资源占用情况很大，操作复杂，有没有简单易用不需安装的流程图制作软件呢？下面我给大家推荐几款在线流程图制作工具。
Gliffy支 持中文，其功能满足你正常的需要，有很多流程图实体供你选择。作为一种在线工具，它继承了协同的概念，你可以和你的同事共同编辑，完成流程图的制作；如果 你需要在博客调用，它也可以使你的博客上的图表与其同步更新；如果你需要在VISIO、或矢量制图软件（如Freehand等）中再加工，可以直接导入。
很可爱的主页面哦。。
非常的简单、轻巧 ，当然 功能也比较少，只能话流程图。
当然后面听说还来了一个新版的，功能有所加强。。。不过地址也换了一个 新版地址入口
这个我是亲身用过的 ，并且现在有的时候 我还是会用。而且有流程图、网络图等等。
免费的，你只需要注册一下就OK了 30天的试用期。不过，如果你不想付款的话，那么你可以随便注册，你只要随便填一个邮箱就可以了。很方便哦。
重点推荐。。。
中文的。。。没用过。你们可以进去体会体会。
在线PS，没搞错吧？这个真的木有。。。不信你打开来看看，其实这个应该不算这里的，可是忍不住就发过来。。。别见怪哈。
很酷吧。等你哪天要ps的时候，就不用在安装庞大的 那个软件了啦。
就这么几个吧。够用就行。。
redis是一个key-value存储系统。和Memcached类似，它支持存储的value类型相对更多，包 括string(字符串)、list(链表)、set(集合)、zset(sorted set –有序集合)和hash（哈希类型）。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是 原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性 的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从…
因为是初次使用，所以是在windows下进行安装和使用，参考了几篇博客，下面整理一下
官方网站：http://redis.io/
官方下载：http://redis.io/download 可以根据需要下载不同版本
windows版：https://github.com/MSOpenTech/redis
github的资源可以ZIP直接下载的（这个是给不知道的同学友情提示下）
下载完成后 可以右键解压到 某个硬盘下 比如D:\Redis\redis-2.6
在D:\Redis\redis-2.6\bin\release下 有两个zip包 一个32位一个64位
根据自己windows的位数 解压到D:\Redis\redis-2.6 根目录下
进入redis目录后 开启服务 （注意加上redis.conf）
redis-server.exe redis.conf
BUG作者：许晓
Bug标题：Dubbo超时机制导致的雪崩连接
Bug影响：Dubbo服务提供者出现无法获取Dubbo服务处理线程异常，后端DB爆出拿不到数据库连接池，导致前端响应时间异常飙高，系统处理能力下降，核心基础服务无法提供正常服务。
Bug发现过程：
线 上，对于高并发的服务化接口应用，时常会出现Dubbo连接池爆满情况，通常，我们理所应当的认为，这是客户端并发连接过高所致，一方面调整连接池大小， 一方面考虑去增加服务接口的机器，当然也会考虑去优化服务接口的应用。很自然的，当我们在线上压测一个营销页面（为大促服务，具备高并发）时，我们遇到了 这种情况。而通过不断的深入研究，我发现了一个特别的情况。
场景描述：
压力从Jmeter压至前端web应用marketingfront，场景是批量获取30个产品的信息。wsproductreadserver有一个批量接口，会循环从tair中获取产品信息，若缓存不存在，则命中db。
压测后有两个现象：
1）Dubbo的服务端爆出大量连接拿不到的异常，还伴随着无法获取数据库连接池的情况
2)Dubbo Consumer端有大量的Dubbo超时和重试的异常，且重试3次后，均失败。
3)Dubbo Consumer端的最大并发时91个
Dubbo Provider端的最大并发却是600个，而服务端配置的dubbo最大线程数即为600。
这个时候，出于性能测试的警觉性，发现这两个并发数极为不妥。
按照正常的请求模式，DubboConsumer和DubboProvider展示出来的并发应该是一致的。此处为何会出现服务端的并发数被放大6倍，甚至有可能不止6倍，因为服务端的dubbo连接数限制就是600。
此处开始发挥性能测试各种大胆猜想：
1）是否是因为服务端再dubboServerHandle处理请求时，开启了多线程，而这块儿的多线程会累计到Dubbo的连接上，dragoon采集的这个数据可以真实的反应目前应用活动的线程对系统的压力情况；
2）压测环境不纯洁？我的小伙伴们在偷偷和我一起压测？（这个被我生生排除了，性能测试基本环境还是要保持独立性）
3）是否是因为超时所致？这里超时会重试3次，那么顺其自然的想，并发有可能最多会被放大到3倍，3*91=273<<600….还是不止3倍？
有了猜想，就得小心求证！
来源：http://rensanning.iteye.com/blog/1548162
fastutil扩展了 Java集合框架，通过提供特定类型的map、set、list和queue，以及小内存占用、快速访问和插入；也提供大（64位）array、set 和 list，以及快速、实用的 二进制文件和文本文件的I/O类。它是自由软件，依照Apache许可证2.0发布，需要Java 6或更高版本。
类实现其标准接口（例如， map 的 Map），可以插入现有代码。此外，它们还提供未在标准类的附加??功能（如双向迭代器） 。
除了 对象和基本类型，fastutil类提供支持引用（references），即使用相等运算符，而不是比较对象的equals（）方法。
源代码由C预处理器生成，从一组驱动文件开始。您可以在查看javadoc生成的文档。尤其是概述说明中fastutil使用的设计选择。
大数据结构
使用fastutil 6类的一组新类，使得它可以处理非常大的集合，特别是其规模超过2 31 。大数组是数组的数组，由一个神奇的静态方如果是带有64为索引的单位数组； big list 提供64位列表索引，hash big set 的 大小是只受限于核心内存量。常用的方法来自java.util.Arrays，类似的类已经扩展到大数组：可查看Javadoc关于 BigArrays和 IntBigArrays 的文档，以获得通用和特定类型的可用方法 。
虽然JCF(Java Collections Framework)在设计做的很好，但是从性能很功能上都有一定的局限性，所有出现很多的扩展JDK的集合框架出现，除了fastutil之外，主要的 JDK集合框架的扩展还有以下这么多，他们都各自有各自的特点，各有所长：
… 阅读全文