大数据Kafka中常用Message Queue有哪些区别呢？

常用Message Queue对比

31　RabbitMQ

RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。

32　Redis

Redis是一个基于Key-Value对的NoSQL数据库，开发维护很活跃。虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。

33　ZeroMQ

ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZeroMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演这个服务器角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果宕机，数据将会丢失。其中，Twitter的Storm 090以前的版本中默认使用ZeroMQ作为数据流的传输（Storm从09版本开始同时支持ZeroMQ和Netty作为传输模块）。

34　ActiveMQ

ActiveMQ是Apache下的一个子项目。 类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。

35　Kafka/Jafka

Kafka是Apache下的一个子项目，是一个高性能跨语言分布式发布/订阅消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现负载均衡；支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制统一了在线和离线的消息处理。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。

上图中一个topic配置了3个partition。Partition1有两个offset：0和1。Partition2有4个offset。Partition3有1个offset。副本的id和副本所在的机器的id恰好相同。

如果一个topic的副本数为3，那么Kafka将在集群中为每个partition创建3个相同的副本。集群中的每个broker存储一个或多个partition。多个producer和consumer可同时生产和消费数据。

　　OWIN 的全称是 "Open Web Interface for NET"， OWIN 在 NET Web 服务器和 NET Web 应用之间定义了一套标准的接口， 其目的是为了实现服务器与应用之间的解耦， 鼓励为 NET Web 应用开发简单模块。

　　OWIN 是一个开源开放的标准， 有助于建设 NET 开发的开源生态环境，OWIN 定义了如下几个概念：

服务器 (Server)

HTTP 服务器直接与客户端交互， 并用 OWIN 语义处理请求，服务器需要一个适配层将客户请求转换 成 OWIN 语义。 支持 OWIN 的服务器有 Katana 和 Nowin 。

Web 框架 (Web Framework)

构建在 OWIN 之上的自包含的独立组件， 向 Web 应用提供可用的对象模型或者接口。 Web 框架可 能需要一个适配层来转换 OWIN 语义。 支持 OWIN 的 Web 框架有：

Nancy

SignalR

WebApi

FubuMVC

SimpleWeb

DuoViaHttp

Web 应用 (Web Application)

一个特定的 Web 应用， 通常构建在 Web 框架之上， 使用 OWIN 兼容的服务器运行。

中间件 (Middleware)

特定目的的服务器和应用之间的可插拔组件， 可以监视、 路由、 修改请求与响应。

宿主 (Host)

应用与服务器所在的进程， 主要负责应用的启动， 有些服务器自身也是宿主， 比如 Nowin 。

　　为什么使用 OWIN

　　正如上面所说， OWIN 定义了 NET Web 服务器与 NET Web 应用之间的标准接口， 将应用与服务器 解耦， 使得便携式 NET Web 应用以及跨平台的愿望成为现实， 标准的 OWIN 应用可以在任何 OWIN 兼容的服务器上运行， 不再依赖与 Windows 和 IIS 。

　　怎么使用 OWIN

　　OWIN 通过 NuGet 包的形式发布， 获取和使用都非常方便。 下面就先建立一个最简单的 OWIN 应用：

打开 Xamarin Studio， 新建一个 C# 命令行程序， 如下图所示：

OWIN Hello

然后打开项目属性， 确认目标框架设置为 Mono/NET 45 ， 如下图所示：

向项目中添加如下几个 NuGet 包：

Owin

MicrosoftOwin

MicrosoftOwinHosting

MicrosoftOwinHostHttpListener

添加一个 OWIN Startup 类， 代码如下：

public class Startup {

public void Configuration(IAppBuilder appBuilder) {

appBuilderRun(HandleRequest);

}

static Task HandleRequest(IOwinContext context) {

contextResponseContentType = "text/plain";

return contextResponseWriteAsync("Hello, world!");

}

}

OWIN 约定的处理请求的代理类型是：

Func<IOWinContext, Task> handler

对应上面 Startup 类的 HandleRequest 方法， 所以上面的 Startup 类就定义了一个最简单的 OWIN 应用， 向客户端输出 Hello， World！

在自动生成的 Programcs 文件中的 Main 方法中添加如下代码， 来启动 OWIN 应用：

class MainClass {

public static void Main(string[] args) {

var url = "http://localhost:8080/";

var startOpts = new StartOptions(url) {

};

using (WebAppStart<Startup>(startOpts)) {

ConsoleWriteLine("Server run at " + url + " , press Enter to exit");

ConsoleReadLine();

}

}

}

现在开始运行程序， 命令行显示如下：

打开浏览器， 访问 http://localhost:8080/ ， 得到的响应如下：

OWIN Hello

　　到目前为止， 没有 Windows ， 更没有 IIS ， OWIN 应用就能正常运行了。

UWP (通用 Windows 平台) 应用开发者在构建通过 HTTP 与 Web 服务或服务器断点交互的应用时，有多种 API 可以选择。要在一个托管 UWP 应用中实现 HTTP 客户端角色，最常用也是推荐的两种 API 即 SystemNetHttpHttpClient 和 WindowsWebHttpHttpClient 。 相对于 WebClient 以及 HttpWebRequest 等老旧过时的 API，应当优先选择上述两种 API（尽管出于向后兼容的考虑， HttpWebRequest 的一个小子集在 UWP 中仍然可用）。

很多开发对于 UWP 中的上述两个 API 有着功能异同、如何选择等疑问。本文旨在解答这些疑问并阐明两个 API 各自的用途。

概述

SystemNetHttpHttpClient 这一 API 在 NET 45 中被首次引入，同时也有一个变体以 NuGet 包的形式为 NET 40 以及 Windows Phone 8 Silverlight 应用提供支持。该 API 的目的在于提供一种比老旧的 HttpWebRequest API 更为简单明了的抽象层，以及更为弹性灵活的 HTTP 客户端角色的实现方法。例如，开发者可以通过其提供的链式自定义 handler，拦截每个请求或响应并实现自定义逻辑。直到 Windows 81 位置，该 API 的底层都是由纯 NET 实现的。在 Windows 10 中，该 API 的 UWP 实现已经改为基于 WindowsWebHttp 和 WinINet HTTP 协议栈实现了。

另一方面， WindowsWebHttpHttpClient API 则在 Windows 81 被引入，并同时可用于 Windows Phone 81。创建这一 API 的最大动因在于整合各种 Windows 应用开发语言可用的 HTTP API，使一种 API 能够提供这些语言各自 API 的全部特性。其中大部分基础 API 的设计均来源于 SystemNetHttp ，而其实现则是基于WinINet HTTP 协议栈。

在 Windows 商店应用中使用上述两种 API时，操作系统版本以及编程语言的支持情况如下：

API 操作系统版本 支持语言

SystemNetHttpHttpClient Windows, Windows Phone 8 以上 仅限 NET 语言

WindowsWebHttpHttpClient Windows, Windows Phone 81 以上 所有 Windows 商店应用语言

如何选择？

两种 API 在 UWP 中均可用，因而 HTTP 开发者面临的最大问题就是该在应用中选择二者中的哪一种。选择结果要依一些具体因素而定。

你是否需要整合原生 UI 以收集用户凭据、控制 HTTP 患侧读写行为或传递指定 SSL 客户端证书用于验证？如果是，则使用 WindowsWebHttpHttpClient 。截至撰写本文时，相对于 SystemNetHttp API， WindowsWebHttpHttpClient API 提供了更多对 HTTP 设置的掌控能力。未来 SystemNetHttp API 可能也会得到加强以提供这些特性。

你是否要编写跨平台 NET 代码（通用于 UWP/ASPNET 5/iOS 以及 Android 平台）？如果是，则使用 SystemNetHttp API。使用该 API 编写的代码可以在 ASPNET 5 以及 NET Framework 桌面应用程序等其它平台上复用。感谢 Xamarin，如今该 API 也支持在 iOS 和 Android 平台上使用，所以你的代码也可以在这些平台上复用。

对象模型

现在我们已经了解了创建这两个相似 API 的原因以及如何选择的基本原则，接下来深入了解一下它们各自的对象模型。

SystemNetHttp

该 API 对象模型的顶级抽象层是 HttpClient 对象。 HttpClient 对象表示 HTTP 协议描绘的客户端-服务端模型中的客户端实体。客户端可以向服务端发送多个请求（由HttpRequestMessage 表示）并接收相应的响应（由 HttpResponseMessage 表示）。每个 HTTP 请求或响应的 entity body 和 content header 由基类 HttpContent 及其派生类 StreamContent 、 MultipartContent 和 StringContent 等表示。这些类型分别代表了不同类型的 HTTP entity body。这些类型均提供了一组 ReadAs 方法将一个请求或响应的 entity body 读出为字符串、字节数粗或流。

每个 HttpClient 对象底层均有一个 handler 对象表示所有客户端 HTTP 相关设置。你可以从概念上把 handler 理解为客户端底层的 HTTP 栈。它负责把客户端的 HTTP 请求发送至服务器并传回相应的响应。

SystemNetHttp API 中默认使用的 handler 类是 HttpClientHandler 。当你创建一个 HttpClient 对象的新实例时——例如，调用 new HttpClient() ——一个 HttpClientHandler 对象都会自动创建，并携带默认的 HTTP 栈设置。如果你想要修改缓存行为、自动压缩、凭据或代理等设置，你可以自己创建 HttpClientHandler的实例，修改其相应属性再传递给 HttpClient 的构造函数：

HttpClientHandler myHandler = new HttpClientHandler();

myHandlerAllowAutoRedirect = false;

HttpClient myClient = new HttpClient(myHandler);

链式 Handler

SystemNetHttpHttpClient API 设计中的一个关键优势就是可以在一个 HttpClient 对象底层插入自定义 handler，并创建一条 handler 对象链。假设你要构建一个需要从 Web 服务查询数据的应用。你编写了自定义逻辑来处理从服务器返回的 HTTP 4xx（客户端错误） 和 5xx（服务端错误） 错误，并发起更换端点或添加用户凭证等重试动作。而你也想要将这部分与 HTTP 相关的工作与其它处理 Web 服务返回数据的业务逻辑分开。

要实现上述需求，可以从 DelegatingHandler 派生一个新的 handler 类（例如 CustomHandler1），再创建一个派生类的实例传递给 HttpClient 的构造函数。 DelegatingHandler 类的 InnerHandler 属性用于指定链中的下一个 handler ——举例，你可以借此把另一个自定义 handler （例如 CustomHandler2）添加到链中。而在最后一个 handler 里，你可以把 InnerHandler 设置为一个 HttpClientHandler 实例，该实例会将请求传递给系统的 HTTP 栈。过程如下图所示：

完成上述需求的示例代码：

public class CustomHandler1 : DelegatingHandler

{

// 此处放置构造和其它代码。

protected async override Task<HttpResponseMessage> SendAsync(

HttpRequestMessage request, CancellationToken cancellationToken)

{

// 在此处理 HttpRequestMessage 对象。

DebugWriteLine("Processing request in Custom Handler 1");

// 一旦前步骤完成，调用 DelegatingHandlerSendAsync 继续将其传递至 inner handler

HttpResponseMessage response = await baseSendAsync(request, cancellationToken);

// 在此处理返回的 HttpResponseMessage 对象。

DebugWriteLine("Processing response in Custom Handler 1");

return response;

}

}

public class CustomHandler2 : DelegatingHandler

{

// 内容与 CustomHandler1 类似

}

public class Foo

{

public void CreateHttpClientWithChain()

{

HttpClientHandler systemHandler = new HttpClientHandler();

CustomHandler1 myHandler1 = new CustomHandler1();

CustomHandler2 myHandler2 = new CustomHandler2();

// 将两个 Handler 链接在一起。

myHandler1InnerHandler = myHandler2;

myHandler2InnerHandler = systemHandler;

// 使用链中的顶级 Handler 创建客户端对象。

HttpClient myClient = new HttpClient(myHandler1);

}

}

注意：

如果你打算向一个远程服务器端点发送请求，通常链中的最后一个 handler 都是 HttpClientHandler ，该 handler 负责实际通过系统的 HTTP 栈发送请求并接收响应。 若非如此，你可以使用一个自定义 handler 模拟发送请求以及接收模拟响应的过程。

在将请求传递到下一个 handler 之前，或在前一个返回响应之前添加处理逻辑可能会带来性能损失。在这类场景中最好避免开销昂贵的同步操作。

有关链式 Handler 的更多信息，可以参阅 Henrik Nielsen 撰写的 文章 （注意该文中谈及的 API 是指 ASPNET Web API 版本的，与我们在本文中谈论的 NET Framework 版略有区别，不过有关链式 handler 的概念是通用的。）

WindowsWebHttp

WindowsWebHttp API 的对象模式与上文中描述的 SystemNetHttp 非常类似，它也有客户端实体、handler（该命名空间内叫做 "filter"，即过滤器）以及在客户端与系统默认 filter 之间插入自定义逻辑等概念。

本 API 中大部分类型与 SystemNetHttp 的对象模型类似：

HTTP 客户端角色表示 SystemNetHttp 类型 对应 WindowsWebHttp 类型

客户端实体 HttpClient HttpClient

HTTP 请求 HttpRequestMessage HttpRequestMessage

HTTP 响应 HttpResponseMessage HttpResponseMessage

HTTP 或响应的 entity body HttpContent IHttpContent

HTTP 内容的字符串、流等表示 StringContent, StreamContent and ByteArrayContent HttpStringContent, HttpStreamContent and HttpBufferContent respectively

HTTP 栈/设置 HttpClientHandler HttpBaseProtocolFilter

用于创建自定义 handlers/filters 的基类/接口 DelegatingHandler IHttpFilter

上文中关于 SystemNetHttp API 链式 handler 的讨论亦可用于 WindowsWebHttp API。你可以创建一组链式自定义 filter，传递给 HttpClient 对象的构造函数。

实现常见 HTTP 场景

现在我们来看看一些代码片段，分别使用两种 HttpClient API 实现常见 HTTP 场景。更多细节和指导可以查阅 WindowsWebHttpHttpClient 和 SystemNetHttpHttpClient 的 MSDN 文档。

修改头

SystemNetHttp:

修改 HttpClient 实例发出的所有请求的头：

var myClient = new HttpClient();

myClientDefaultRequestHeadersAdd("X-HeaderKey", "HeaderValue");

myClientDefaultRequestHeadersReferrer = new Uri("http://wwwcontosocom");

只修改特定请求的头：

HttpRequestMessage myrequest = new HttpRequestMessage();

myrequestHeadersAdd("X-HeaderKey", "HeaderValue");

myrequestHeadersReferrer = new Uri("http://wwwcontosocom");

WindowsWebHttp:

上述代码同样适用于 WindowsWebHttp API。

注意：

部分头项目是集合，修改需要通过 Add 和 Remove 方法实现。

HttpClientDefaultRequestHeaders 属性表示在应用层次上，默认头集合是否会添加到请求中。由于请求是由系统的 HTTP 栈处理的，所以请求实际发送出去前，一些附加头可能会添加到请求中。

超时设置

SystemNetHttp:

在 SystemNetHttp API 中，有两种方式设置超时。要为客户端发出的所有请求设置超时，使用：

myClientTimeout = TimeSpanFromSeconds(30);

要为单个请求设置超时，则使用 CancellationToken:

var cts = new CancellationTokenSource();

ctsCancelAfter(TimeSpanFromSeconds(30));

var httpClient = new HttpClient();

var resourceUri = new Uri("http://wwwcontosocom");

try

{

HttpResponseMessage response = await httpClientGetAsync(resourceUri, ctsToken);

}

catch (TaskCanceledException ex)

{

// 因超时取消请求的逻辑

}

catch (HttpRequestException ex)

{

// 处理其它可能异常的逻辑

}

WindowsWebHttp:

WindowsWebHttpHttpClient 类型中没有超时属性可用，因此你必须向上文一样使用 CancellationToken 实现超时处理。

使用身份验证凭据

SystemNetHttp:

为了保护用户的凭证信息，HTTP 栈默认不会向发出的请求添加任何验证凭据。要使用指定用户的凭据，可以使用如下方法：

var myClientHandler = new HttpClientHandler();

myClientHandlerCredentials = new NetworkCredential(myUsername, myPassword);

WindowsWebHttp:

对于 WindowsWebHttp API，默认情况下如果发出的请求访问了要求用户验证的资源，系统会弹出一个 UI 对话框。要关闭 UI 对话框，可以把 HttpBaseProtocolFilter 的 AllowUI 属性设置为 false。要使用指定用户的凭据，可以使用如下方法：

var myFilter = new HttpBaseProtocolFilter();

myFilterServerCredential = new PasswordCredential(“fooBar”, myUsername, myPassword);

注意：

在上述示例中， myUsername 和 myPassword 两个字符串变量可以来自用户通过 UI 输入或者应用自身的配置。

在 UWP 应用中， HttpClientHandlerCredentials 只能设置为 null、 DefaultCredentials 或一个 NetworkCredential 类型的对象实例。

使用客户端证书

SystemNetHttp:

为保护用户的凭据信息，该 API 默认不会向服务器发送任何客户端证书。要使用客户端证书用于验证，使用如下方法：

var myClientHandler = new HttpClientHandler();

myClientHandlerClientCertificateOptions = ClientCertificateOptionAutomatic;

WindowsWebHttp:

使用该 API 进行客户端证书验证有两种选择——默认方式是弹出一个 UI 让用户选择证书；另一种选择是在代码中自行指定一个客户端证书：

var myFilter = new HttpBaseProtocolFilter();

myFilterClientCertificate = myCertificate;

注意：

无论使用哪种 API ，要使用客户端证书，你必须先根据 这些步骤 将证书添加到应用的证书储存区。拥有企业权限的应用也能够使用用户的“我的”储存区中已经存在的证书。

HttpClientHandlerClientCertificateOptions 属性允许两种值： Automatic 和 Manual 。设置为 Automatic 则会从应用的证书储存区自动选择最佳匹配的证书用于验证。设置为 Manual 则会保证在服务器请求前，任何客户端证书都不会被发送。

代理设置

默认情况下，两种 API 的代理设置都会自动根据 Internet Explorer/ Microsoft Edge 的设置自动为所有 HTTP 调用进行配置。这使得应用在用户通过代理连接网络时也能正常工作。两种 API 都没有提供任何方法为应用指定一个自定义代理。然而你可以通过在 SystemNetHttp 中设置 HttpClientHandlerUseProxy 为 false 或在 WindowsWebHttp 中设置 HttpBaseProtocolFilterUseProxy 为 false 来禁止使用默认代理配置。

Cookie 处理

默认情况下，两种 API 都会保存服务器发来的 cookie 数据，并自动附加到随后产生的请求对相同应用容器 URI 的请求中。对特定 URI 的 cookie 也能读取或添加自定义 cookie 数据。最后，两种 API 都提供了选项来关闭向服务器发送 cookie：对于 SystemNetHttp ，将 HttpClientHandlerUseCookies 设置为 false；对于 WindowsWebHttp ，设置 HttpBaseProtocolFilterCookieUsageBehavior 为 HttpCookieUsageBehaviorNoCookies 。

SystemNetHttp:

为客户端生成的所有请求添加一个 cookie：

// 手动添加cookie。

myClientHandlerCookieContainerAdd(resourceUri, myCookie);

为单个请求添加 cookie：

HttpRequestMessage myRequest = new HttpRequestMessage();

myRequestHeadersAdd("Cookie", "user=foo; key=bar");

查看给定 URI 的所有 cookie：

var cookieCollection = myClientHandlerCookieContainerGetCookies(resourceUri);

WindowsWebHttp:

为客户端生成的所有请求添加一个 cookie：

// 手动添加cookie。

filterCookieManagerSetCookie(myCookie);

上文中为单个请求添加 cookie 的示例同样适用于 WindowsWebHttp API。

管理 cookie：

// 获取给定 URI 的所有 cookies。

var cookieCollection = filterCookieManagerGetCookies(resourceUri);

// 删除一个 cookie。

filterCookieManagerDeleteCookie(myCookie);

注意：

在 WindowsWebHttp API 中，对于应用容器内的 WindowsWebSyndication 、 WindowsWebAtomPub 以及 XHR 等几个使用 WinINet 栈实现的网络 API之间，cookie 管理器内的 cookie 数据是共享的。因此，之前一个 Syndication API 调用通过服务器响应获得 cookie 可能会被添加到相同应用容器内之后发送给同一服务器的 HttpClient 请求里。

每服务器最大连接数

默认情况下，操作系统底层的 HTTP 栈对每个服务器最多使用六个连接。 SystemNetHttp 的 HttpClient API没有提供任何方法控制最大连接数。对于 WindowsWebHttp API，可以使用如下方法设置：

var myFilter = new HttpBaseProtocolFilter();

myFilterMaxConnectionsPerServer = 15;

我自己以前都是先安装vs2013然后安装mysql版本56260msi。里面自带了mysql-for-visualstudio-123的链接器。安装的时候就有了。可是重装了系统安装了vs2015再安装56260msi之后。发现创建EF连接器的时候找不到mysql的dababase，然后我用电脑管家看了也找不到安装 mysql-for-visualstudi123的迹象我去C盘发现了 mysql-for-visualstudi12的目录。。。。肯定是这个没有正确的安装吧（我没有删除这个文件）。于是到网上重新下载了 mysql-for-visualstudio-127的。关闭vs2015和mysql的服务。安装之后。开启mysql服务。重新打开vs2015完美解决了。

多屏幕伤眼，自带搜索不给力，重复性操作太多浪费精力等等，都是很多同学遇到过的问题，今天推荐一点特别的软件，不仅都是省时省力的神器，且可玩性极高，保证让你眼前一亮，不多说，赶紧按指南来下载吧！

小提醒：本文涉及谷歌的软件都得自备梯子呦。

@belleveinvis ：top10 是：

Chocolatey

名字很奇特，但它可是 Windows 上的 apt-get。一旦拥有，别无所求。（具体见：wwwhanselmancom）现在我想装软件的时候，会首先想到它而不是 Google。刚刚我还在用 ‘cinst filezilla’ 和 ‘cinst winscp’ 来安装我想要的东西呢。想想看，利用它你就可以把「装机」变成一个极其简单的事情。不过自己写脚本还是太复杂，对于装机，你应该用……

TeraCopy

大多数时候我都用 Windows 81 自带的复制，不过如果我真要搬运一大堆东西的话我会用 TeraCopy。正如其名它做的事情就是复制，而且在速度上，无出其右。

Boxstarter

Matt Wrock 利用 Chocolatey 和 Nuget 构建了这个神奇的东西。它可以大幅简化你在更新电脑时候的工作，也可以在远程机器或者虚拟机上进行无人值守的环境部署。

NimbleText

正则表达式很难写，我也学不会。NumbleText 则可以让你轻松地处理大量文字。

GOW Gnu on Windows

当你只需要 nix 工具的时候装 Cygwin 未免小题大做。

Gow 就是130 个编译成原生 Windows EXE 的 Unix 命令行工具（https://githubcom），仅此而已。

Flux

设计师必备有木有！

说实话，一开始我觉得这玩意挺蠢的，但是再用完几天之后我就收回了那些想法。Flux 会随着每天时间的变化来调整显示器色温，在晚上就能让显示器色调更暖。对于一个整天对着三个巨屏的人来说这是福利。自从用来 Flux 我再也不头痛了，眼酸的症状也缓解了很多。试试看，你会喜欢上的。

AutoHotKey

这个开源小东西碉堡了。你可以把复杂的工作变成简单的快捷键，非程序员的变成利器。它可以用极其简单的方法来自动化 Windows 操作，堪称 Windows 平台的 Applescript。

PaintNET

Windows 应该内置的画图程序，基于 NET 平台，用免费的价格换取 Photoshop 80% 的能力。目前 PaintNET 正在积极开发它的第四版！

如果你写英语的话千万别错过 “AuftoCorrect for English” （wwwautohotkeycom）脚本。它可以在几乎所有的 Windows 程序里纠正超过 4700 种拼写错误。是的，所有程序。它只是 AHK 强大能力的冰山一角。

别忘了Window Pad（wwwautohotkeycom） - 超赞的好东西，完全是用 AHK 写成的！

7-Zip

不用再关心其他的压缩软件了。7z 已经胜利，它能提供比 zip 更高的压缩比，更好的 Windows 整合性，而且也能打开 TAR、ISO、RAR 和 CAB。

DropBox

自备梯子呦。

现在的云存储多到爆。Skydrive、DropBox 和 Google Drive，等等等等，不一而足。我现在回到了 Dropbox 的怀抱，因为它们处理大量文件效果更好，可以提供选择性同步，而且在每个平台都有客户端。赶快选个云盘吧，放那里总是更安心的，不是么？

国内的百度云、微盘、360云盘都蛮不错的，而且不受梯子限制，优设的资源都在微盘，这里推荐一下 ^ ^

顺便插播下载量最高的几组设计资源：

《PS抠图神器：KNOCKOUT 20汉化版下载及教程》

《这效果超火！教你创建高大上的多边形字体》

《PS 参考线插件GUIDEGUIDE下载及使用说明》

Windows Live Writer

如果你有博客，那它是神器。它还有一个不错的插件库（http://pluginslivecom）。它应该停止更新了，但生命力依旧旺盛。

以下是@UperOne 的推荐，同学们有什么日常的好用软件，也欢迎留言呦！

本地磁盘搜索工具：

Everything：Everything Search Engine（wwwvoidtoolscom）

Listary：Listary – Fabulous search utility（wwwlistarycom）

百度硬盘：百度硬盘搜索（diskbaiducom）

资源管理工具：

Total Commander：Total Commander（wwwghislercom）

Clover，给资源管理器加上类似Chrome的标签（http://cnejieme）

个人知识管理工具：

有道云笔记：（http://noteyoudaocom）

麦库记事，永不丢失的云中记事本（http://notesdocom）

为知笔记：（wwwwizcn）

Evernote，让记忆永存（wwwyinxiangcom）

源码阅读工具：

Source insight：（http://sourceinsightcom）

Vim：（wwwvimorg）

文件比较工具：

Beyond Compare：（wwwscootersoftwarecom）

源码管理工具：

Github for Windows：（http://windowsgithubcom）

Git：（https://codegooglecom）

Svn：（http://tortoisesvnnet）

Cvs：（wwwtortoisecvsorg）

磁盘恢复工具：

Diskgenius（wwwdiskgeniuscn）

文件查看工具：

Winhex：（winhexensoftoniccom）

UltraEdit：（wwwultraeditcom）

流程图工具：

Visio：专业制图软件（http://officemicrosoftcom）

FTP服务器：

FileZilla：（https://filezilla-projectorg）

思维导图工具：

Mindjet：（wwwmindjetcom）

电子书阅读工具：

百度阅读器：（http://yueduqibaiducom）

福昕阅读器：（http://wwwfoxitsoftwarecn）

GTD、备忘工具：

Doitim：（http://doitimcom）

小孩桌面便签：（wwwnotesmakercom）

日历：

谷歌日历：（wwwgooglecom）

人生日历：（http://rili160com）

资源下载：

章鱼搜索：（wwwhappygolifecom）

~~~~~~~~~~~~~~华丽的分割线~~~~~~~~~~~~~~~~~~~~

知友啊，如果我的回答能让您满意的话，给个最佳采纳吧，您的采纳是我坚持不懈的动力哦(^__^) ~