1. 通常JAVA WEB 开发用到哪些技术工具
在实际开发中，我们都会有一个技术选型的过程，因为每个项目的要求不一样，规模不一样，要求的性能不一样等等诸多因素，因此单独说用什么技术工具其实很难回答，一般都是看具体你们的项目需求来确定的，我就简单说一说吧。
一、 开发工具
开发工具这一块，首先是IDE，可以选择免费的Eclipse，但是Eclipse比较耗内存，多开几个你电脑估计内存就不够用了，另外是IntelliJ IDEA， 这个是我现在使用的，比较推荐的一个IDE，代码提示功能强大，很流畅，开多少个都可以。然后你要准备一下Notepad++或是VIM等编辑器。
二、后台技术框架
其实这么讨论没啥意义，就说个普通的吧，一般用Struts2， SpringMVC， Spring， Hibernate， MyBatis， 可以相互组合，常见的一般用SpringMVC + MyBatis，我们公司用的就是SpringMVC，这是大致的情况
如果要用缓存，可以选择Redis或是Memcached，我们选择了Redis
如果要用消息队列，可以选择ActiveMQ或是RabbitMQ等
如果想使用分布式锁，可以使用Zookeeper或是Redis
。。。。。。
一句话，看你项目的具体需求来确定用什么技术框架
2. 消息队列的消费者是谁来承担
我的理解web后台是消费者。
生产者是前端。比如用户需要登录，那么前端就发送一个登录的需求给消息队列，web后台作为消费者，满足用户的登录需求。
3. 在应用程序中消息队列可以做哪些工作
利用 MSMQ（Microsoft Message Queue），应用程序开发人员可以通过发送和接收消息方便地与应用程序进行快速可靠的通信。消息处理为您提供了有保障的消息传递和执行许多业务处理的可靠的防故障方法。
MSMQ与XML Web Services和.Net Remoting一样，是一种分布式开发技术。但是在使用XML Web Services或.Net Remoting组件时，Client端需要和Server端实时交换信息，Server需要保持联机。MSMQ则可以在Server离线的情况下工作，将Message临时保存在Client端的消息队列中，以后联机时再发送到Server端处理。
显然，MSMQ不适合于Client需要Server端及时响应的这种情况，MSMQ以异步的方式和Server端交互，不用担心等待Server端的长时间处理过程。
虽然XML Web Services和.Net Remoting都提供了[OneWay]属性来处理异步调用，用来解决Server端长方法调用长时间阻碍Client端。但是不能解决大量Client负载的问题，此时Server接受的请求快于处理请求。
一般情况下，[OneWay]属性不用于专门的消息服务中。
1. 基本术语和概念（Basic terms and concepts）
“消息”是在两台计算机间传送的数据单位。消息可以非常简单，例如只包含文本字符串；也可以更复杂，可能包含嵌入对象。
消息被发送到队列中。“消息队列”是在消息的传输过程中保存消息的容器。消息队列管理器在将消息从它的源中继到它的目标时充当中间人。队列的主要目的是提供路由并保证消息的传递；如果发送消息时接收者不可用，消息队列会保留消息，直到可以成功地传递它。
“消息队列”是 Microsoft 的消息处理技术，它在任何安装了 Microsoft Windows 的计算机组合中，为任何应用程序提供消息处理和消息队列功能，无论这些计算机是否在同一个网络上或者是否同时联机。
“消息队列网络”是能够相互间来回发送消息的任何一组计算机。网络中的不同计算机在确保消息顺利处理的过程中扮演不同的角色。它们中有些提供路由信息以确定如何发送消息，有些保存整个网络的重要信息，而有些只是发送和接收消息。
“消息队列”安装期间，管理员确定哪些服务器可以互相通信，并设置特定服务器的特殊角色。构成此“消息队列”网络的计算机称为“站点”，它们之间通过“站点链接”相互连接。每个站点链接都有一个关联的“开销”，它由管理员确定，指示了经过此站点链接传递消息的频率。
“消息队列”管理员还在网络中设置一台或多台作为“路由服务器”的计算机。路由服务器查看各站点链接的开销，确定经过多个站点传递消息的最快和最有效的方法，以此决定如何传递消息。
4. websphere mq是什么
IBM WebSphere MQ 是IBM公司提供的基于消息队列的消息中间件。
国内相应的产品也有很多，如东方通科技的TONG-LinkQ等。
消息中间件服务于服务器间的消息传递，并通过消息队列机制保障其传输的稳定性。
5. C# web中，只要有数据存到消息队列中，就在页面中滚动显示出来。哪为大侠有什么思路吗
Thisisthecodemodetest!
简单说一下我的思路，不知道可行不可行，
方法一：你可以将你需要显示的内容放入缓存中，每次去缓存中去读，当你保存数据到消息队列的同时去修改这个缓存。（推荐）
方法二：写个服务或定时器，隔段时间重新读数据库（u）
6. 消息队列怎么跟现成的web应用进行整合
消息队列技术是分布式应用间交换信息的一种技术。消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走。通过消息队列，应用程序可独立地执行--它们不需要知道彼此的位置、或在继续执行前不需要等待接收程序接收此消息。
7. 什么是消息队列
MSMQ. 这是微软的产品里唯一被认为有价值的东西。对我的客户来说，如果MSMQ能证明可以应对这种任务，他们将选择使用它。关键是这个东西并不复杂，除了接收和 发送，没有别的；它有一些硬性限制，比如最大消息体积是4MB。然而，通过和一些像MassT...
8. 2017年，Web 后端出现了哪些新的思想和技术
1. 网络交互的多样性
1.1 Http1.1协议日渐式微,Http2和websocket,以及更多的自定义协议将会成为主流。
Web后端将不仅仅是一个web后端，而变成一个大后端，或者叫 中端+后端(这个概念阿里巴巴很早就有了)。随着移动互联网的发展，以及物联网的兴起(在这里我把mobike的单车看作是物联网的一个终端)，用户的接入方式由单纯的浏览器，向着多种接入设备进行演进。 在这个概念之下，用户的定义会更广泛，站在后端的角度看来，连接上服务器的不再是一个个的用户，而是一个个的终端，并存在多个终端同享一个用户的情况(多端登录)。 因此在这个趋势之下，整个后端的接入层(比如nginx之于web)将会走向更广阔的天地，对于任意一个设备来说，他将同时利用多种协议和多种方式连接到不同的接入点来达成自身的功能。
1.2 网络协议与网络信息交互的样式多样性
从最早的webService,到后来的json-rpc，和thrift再到如今的 protobuf(grpc)等等，我们开始为不同的数据交互设计了不同的序列化协议和调用协议，然而受到环境(移动终端的弱网络状态)，性能(网关服务,与网络调用)的影响,我们开始使用大量容错性更强，数据量更小的数据传输方式，来满足我们的需求。
在早先的web中，http+from表单的提交成为我们的标配，然而在今天，TCP都不一定成为必选项，UDP和UDP的改进协议都在被不同的公司进行尝试，甚至于KCP都有可能成为大家考虑的方案之一。
2.数据多样性开始成为设计的焦点。
2.1 在早先的web后端中，表设计和功能开发构成了日常工作的绝大部分，所有的后端人员都在试图让一切的用户操作落入CRUD的抽象范畴里(比如 Restful)，然而CRUD怎么会满足我们的抽象需求呢。
自从memcached和redis在被大量引入后端开发之后，我们可以看到，后端人员在对数据的理解上有了大量的改变，我们不再单单把数据视为RDBMS里面的一行，而是围绕着业务本身对数据进行了分类。最明显的是，状态数据的引入，在开发中，我们将用户的部分信息，视为一个用户的状态，在状态数据的基础上，让用户的行为变成状态迁移的触发，在表现上看我们让用户的信息存储到redis和memcached 里就是最RDMBS不能有效满足我们的抽象需求的一次改进。
2.2 从狂热的Nosql到Nosql和RDBMS的共存，代表了后端开发人员对数据这一个方式的新理解，而传统的行存储到列存储，到监控常用的基于时间序列的数据库都开始进入了我们的视野。
几年来，大量的开发者，开始将用户产生的数据进行了更详细的归类，不再是rdbms一刀切的方式， 我们会详细地划分出用户的状态数据落入到Nosql，将用户的操作数据落入到RDBMS(表述不一定全，但在类似于订单支付之类的具有幂等性要求的操作中要求事务的完备等)，将用户的行为统计落入时间序列数据库， 将用户的大量相关资源(如头像图片)将会落入到我们的对象存储中。在后端开发的手册里，数据格式的多样性成为了必须考虑的问题。
3.围绕着数据的收集,存储，计算，索引查询，分析 成为后端的常态
3.1 后端角色的含义，在人手不足的公司里，很难存在一个专注于后端业务开发的开发人员了，在大数据的浪潮下，后端开发人员开始兼职起了数据系统的开发工程师。 随着互联网大量技术的演进和发展，任何一个职业都很难找到一个明确的界限，因此围绕着数据的收集，存储，计算，分析，和索引查询都会成为后端开发人员的必备技能。
3.2 数据收集
(1) 随着分布式，集群化，多IDC的发展，不同于运维的系统性能收集，后端开发开始着重于收集与应用运营过程相关的各类指标和数据，
除了日常的业务开发，同时还会伴随着应用调用过程的耗时，目标服务可用性等数据的收集，常见的如java的 metrics,zipkin等开源第三方的工具开始被广泛借鉴和引用。
(2) 用户行为和终端信息的上报收集，随着大数据的开展，以及精细化运营的要求，后端逐渐开始接触到用户相关信息和终端运行状态的信息上报，
收集上来的数据不仅用于用户的画像分析，同时也为客服的用户追踪，用户的操作行为做出决策，通常表现在当用户投诉某一笔业务的失败时，便于开发人员的快速定位和排错。
3.3 数据存储
接着上面的数据收集，数据的传输和存储成为了绕不开的功能，kafka的大规模运用，HDFS,HBase等工具也开始成为了后端开发日常的一部分。
3.4 数据计算
然而存储的原始数据是没有价值的，后端又开始了他们的数据清洗和数据处理的道路，storm,spark成为了后端的新秀，与用户运营统计分析(俗称跑策略跑算法)不同，当前语境下的后端数据计算，更多是一个短耗时,小规模的计算，典型的则比如风控系统，和预警系统，针对用户的行为和流量的多少，对恶意用户进行甄别和快速干预。
3.5 数据索引查询
(1) 随着业务的扩充，任意一个app几乎都内置了相应的搜索引擎，Lucene,solr也成为了后端程序员必备的技能之一，不管是精确搜索，还是模糊匹配，后端身上背负的业务也越来越多。
(2) 准实时数据的搜索也将成为常态，在近几年的发展中，如何快速地在一个巨量的数据中，完成RDBMS中的 join,distinct统计等成为后端工程师不得不面对的问题
3.6 数据分析查询
AI和深度学习已经拉开了序幕，围绕着数据本身的挖掘，学习，也开始成为了产品侧的需求，但理想归理想，现实归现实，后端的同学们在这个方向上仍然还是摸索状态，但长远来说跑不了了。
4.架构设计的更进一步
2017年里，SOA的名词正在淡出视野，微服务成了替代SOA的高频词，Serverless也开始走向了广大后端的知识技能图谱，不管是追新也好，满足需求也罢，我也向诸位举例一些常见的单词，然而挂一漏万请诸位担待
4.1 CQRS(命令查询职责分离模式)
将传统CRUD的写操作，进行异步化,后端配合读写数据库的分离。以及消息队列的引入，将写操作相关的一些耗时操作(验证，走流程)等进行异步化，常见的如电商中的订单。
4.2 actor
Erlang的actor的兴起，不管是golang Goroutine，还是scala/java的akka，都在深刻地影响着后端系统的架构设计。
4.3 CRDT和最终一致性
分布式系统的兴起，也带来了可用性和一致性的矛盾问题，协同两个进程间的数据成为了每一个后端绕不过去的坎，为了达成最终一致性，各类方案如雨后春笋般冒出。
4.4 reactive
当android上的流行库Rxjava，从前端走向后台的时候，也意味着后端也开始进入了响应式编程的时代，java的 vert.x就是其中的例子，那种request-response一招破万法的时光不再有了。
5. 运维和devops对后端的要求
5.1 安全,稳定,高效,经济
(1) 随着业务走向稳定，以及互联网的发展，网络服务的安全性开始成为了后端的核心之一，由于法律的不健全，对违法分子的追责难度大，违法成本低，网络安全攻击将会在将来的一段时间内成为常态，这就对后端的程序特别是对外的接口设计提出了更高的要求。
(2) 多机房，异地容灾，数据备份。健壮的后端一直是后端应用的要求之一。新的时间里，后端的可用性，稳定性依然是每一个后端都要面对的问题。
(3) 以前一个用户只有一个电脑，浏览网站的时候，只在获取数据的时候与站点有交互。现在随着电子设备，智能设备的增多，一个用户能够接入网络的设备也在增多，同时长连接和并发数也会增多，因此高性能的接入网关开始成为了后端人员关注的焦点，比如围绕着intel的dpdk各类应用也是纷至沓来。
(4) 经济，利用云服务的即买即用，用完即退的特点，使得在开展运营活动的时候，后端不用向运维征求和购买大量的机器。 然而为了在运营活动的短时冲击和突增流量的情况下后端应用能够平稳地运行，对后端人员的部署和调度能力提出了更高的要求。
5.2 更规范的软件开发流程
git+jenkins+ansible的开源组合，开始无法满足开发和运维的需求，项目管理的集成，测试人员的介入，都要求后端的软件工程工具从各自为阵的开源工具，走向一个大一统的系统，需要我们将 需求,BUG管理,迭代版本，开发，测试，灰度，蓝绿部署流程都进行集成。
5.3 云服务,容器化之争
公有云，私有云，混合云，以及容器等相关的云计算技术，也在推动者后端的技术改革，后端面对的不再仅仅是一个物理机器，或者虚拟机，而是一个更复杂更多样性的环境，对后端业务之外的技术和调度要求将越来越高。
相对于前端，后端实在是一个特别笼统的说法，正如上面提出的观点，很多的技术其实并不属于后端工程师，他们有的时候叫 运营开发工程师，有的叫大数据工程师，但为了相对于前端的划分，因此我把他们的工作内容都划到了后端里面去，毕竟相对于技术研究,他们面对的都是一些技术应用的场合，很多的开源软件只要达到了理解原理如何使用的水平就已经足够应付日常工作了。
9. webservice和消息队列是什么关系
webservice 可以通过soap协议 wsdl文件，在客户端可以获得方法返回对象。客户端可以直接调用web service的公共方法。
消息队列是通过报文来传送。
10. 什么是 Web 框架
在Clojure里有大量的web框架，但是初学者应该把他们自己的服务器栈移动到Ring生态系统。 我经常被Clojure的初学者问到的一个问题是“我应该使用什么web框架？”这是一个好问题。Python有Django。PHP有Drupal。当然Ruby有所有web框架之王，Ruby on Rails。 在Clojure里你应该使用什么框架？实际上这个问题是难以回答的。外面有很多web框架了。有人把 Compojure 叫做框架，虽然它真正是一个类库。 lib-noir 为你做了大量工作。然而有属于你的真正框架，像 Pedestal 或 Hoplon ，它们提供基础功能和解决web开发的抽象。所有这些项目是伟大的，但是对于初学者，我不得不推荐建立你自己的web栈，从Ring开始。 Compojure实际上只是一个路由类库，而不是框架。虽然有 playnice , bidi , Route One 和 gu 等其它替代品，但是你能够用它满足路由需要。如果你不想下决定，那就使用Compojure。它使用广泛、表现优秀。如果你想深入，可以看看其他文档。它们针对不同的场景各有优点。 lib-noir 来自于 Noir ，后者是一个web框架（现在废弃了）。它比较容易，还为你提供了一些管道，因此你刚好借助建好的大量基础设施来开始一个项目。lib-noir是以类库形式存在的基础设施。我还没有用过，但是很多人喜欢它。然而，当我研究它的时候，我发现它提供了太多我不需要的东西，或太过琐碎。如果得到了大规模的应用（像Rails），你就能得到生态系统的效应，这通常是良性的，但是还没有这样。lib-noir被应用了，只是完全不占优势。 Pedestal 有很多支持者。它的目标是通过提供使用ClojureScript、消息队列形式的、一个明智的前端环境来处理单页app。如果你需要“实时app”，它或许为是你准备的。尽管如此，我仍然警告你，它不适合Clojure初学者。Pedestal引入了大量新概念，甚至有经验的Clojure程序员也不得不去学习。 这个教程 又长又费力。如果你不了解Clojure，你去学习Pedestal会遇到问题的。 Hoplon 也是为web app设计的。它为你提供了用ClojureScript实现的DOM（包括自定义组件），数据流编程（像电子表格）和客户端-服务器端通信。这是勇敢的一步，但是再一次，需要你接受花很长时间才能理解的编程模型。如果你还不熟悉Clojure，你就是在自找麻烦。 外面还有其它框架。但是我推荐你考虑自己条件。如果你在学习Clojure，掌握web app如何工作的最好方法就是得到一个配置了一些基本handler的 Ring Jetty适配器。根据需要添加中间件。写一些自己的中间件。使用Compojure做路由。使用 Hiccup 生成HTML。这个安装将让你学到很多。 Ring仅仅是个函数。借助一些基本概念和Ring SPEC，你可以快速建立正是你想要的web服务器，你能够全面理解它。自己建立的经历能够让你在框架如何整合上受益良多。 况且，Ring有优势。大多数人写功能（以中间件或handler的形式）是以Ring为假设、而不是其它。因此保持靠近本质，你就会接近庞大的彼此兼容的、预编写的类库池。Ring就是Clojure web生态系统的所在地。