.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
导读：如何实现服务器向客户端发出一条通知？当向服务器数据库插入一条数据时，服务器就向客户端发出一条信息，让客户端及时知道；如何实现呢？能描述清楚点吗？问题太大概了吧。向客户发送消息的sendMessage方法是不是已经准备好了？那接下来就是选择在
如何实现服务器向客户端发出一条通知？
当向服务器数据库插入一条数据时，服务器就向客户端发出一条信息，让客户端及时知道；
如何实现呢？
能描述清楚点吗？问题太大概了吧。
向客户发送消息的sendMessage方法是不是已经准备好了？
那接下来就是选择在程序中100%确定已经向数据库插入了数据的地方调用sendMessage方法。
简单的实现可以用js的alert方法。
执行数据库插入操作，后返回值，js判断，根据返回的值，如果插入成功，则alert('插入成功')
ejb的拦截器应该能实现，给向数据库插入数据的这个方法加个拦截器，在这个拦截器类里边先调用这个方法，然后实现向客户端发消息
得看你做B/S还是C/S
看不懂说的啥。。
在消息库里插一条 消息数据。 再查询出来 不就好了。 这是简单的方式咯。 复杂点就用推送技术吧
基本上就两招：
要么是 短连接下的客户端发起轮询 模型；
要么是 长连接下的服务器端主动推送 模型。
C/S没玩过，B/S用过推模式，比轮询要好的多
我现在用的数据库连接字符串是private static string conStr = @"Data Source=192168137,1611;Initial Catalog=QLYM;User ID=sa;Pwd=system";这是局域网的！那连接服务器数据库应该什么写呢？
当服务器数据库数据有更新时，客户端如何及时知道？客户端是client的，轮询会对服务器有压力，有什么技术更好的？
客户端只设置两个，每分钟访问服务器一次，这样服务器的压力应该不大吧？
手机推送服务是指服务器定向将信息实时送达手机的服务。为了做好信息推送，同时不会让客户产生反感的情绪，应该注意如下几点：
1、选择合适的人群进行推送：消息推送的时候，将要推送的内容、封面、标题将这些都确定好了之后，再选择合适的人群进行推送，做好这一点其实是很有必要的。
2、适当的运用焦点强占形式：如无必要，不使用焦点强占形式的主动通知形式；如必须采用主动焦点强占形式的通知，则必须提供给用户自行关闭通知或降低通知强度的设置。
3、合理的推送周期：为周期性的和同类型的通知消息提供折叠或分组功能，每天的推送消息尽量不要超过2条，同类型的不要重复推送，而且也要注意好推送时间，如果是在大家休息的时间段，尽量不要推送。
4、智能个性化消息通知：这种类型的通知，用户一般都不会反感，还会觉得挺方便的。
5、掌握消息推送强度：尽量不要把消息通知的强度选择权交给用户。
关于手机推送服务也可以选择第三方工具来帮忙时效，比如极光推送就很不错。深圳市和讯华谷信息技术有限公司（极光 Aurora Mobile，纳斯达克股票代码：JG）成立于2011年，行业应用已经拓展至市场洞察、金融风控与商业地理服务，助力各行各业优化决策、提升效率。
本文场景：
服务器A：服务端，目的是要接收外部数据处理后放入消息队列。
服务器B：客户端，向服务器A提供数据。
前面有文章测试了基于HTTP的方案，但都是基于一台服务器自己测试。实际在外部服务器测试时单机请求性能很差，远远达不到处理能力，网路性能制约严重。
原基于HTTP的方案，每次推送都要重新建立连接，消耗过大。所以想到了Socket长连接方案。
扩展：HTTP使用TCP 三次握手建立连接，客户端和服务器需要交换3个包。HTTPS除了 TCP 的三个包，还要加上 SSL握手需要的9个包，一共是12个包。
服务端和客户端都是基于Workerman建立的
之前HTTP方案的测试受制于发送瓶颈太严重，单台请求能力才几百每秒，多服务器请求服务端速率正常倍增。
remoting 和socket都可以实现推送
例如：服务器段获取后，先分离出数，然后相加，然后发送给客户端。
不过我那个不是C/S的，是点对点的。
补充：服务器，也称伺服器，是提供计算服务的设备。由于服务器需要响应服务请求，并进行处理，因此一般来说服务器应具备承担服务并且保障服务的能力。
服务器的构成包括处理器、硬盘、内存、系统总线等，和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。
在网络环境下，根据服务器提供的服务类型不同，分为文件服务器，数据库服务器，应用程序服务器，WEB服务器等。
不同用户页面的进度条刷新方式：客户端定时刷新、服务器推送。
1、客户端定时刷新：在页面中设置一个定时器，每隔一段时间就向服务器发送请求，获取最新的进度状态，并及时更新页面上的进度条。这种方式会占用一定的带宽和服务器资源，但是能够实现实时刷新，用户体验较好。
2、服务器推送：服务器端可以使用WebSocket或者Server-SentEvents等技术，向浏览器推送最新的进度状态，浏览器接收到推送后及时更新页面上的进度条。这种方式能够实现实时刷新，而且不会占用过多的带宽和服务器资源，但是需要服务器支持相应的技术。
Thank you for your help!问题补充：laorer 写道应该是客户端主动定时去连服务器端，这种操作最好要让用户知道第二个问题应该是不是在用户连接到手机时，存到一个地方，或者内存中，或者数据库中但是现在的需求是当数据库有更新时就要主动发送一个更新通知给所有的客户端，然后客户端接到这个通知后才到服务器端取数据。你说的那是轮询，暂时还不想用这种方法，呵呵。问题补充：laorer 写道如果你只是想把消息发给现在在线的用户的话，那么客户端肯定需要一个监听程序，来监听来自服务器的消息，而服务端则在有新数据时，检查在线的用户并获取相关信息，然后发个消息给客户端的监听端口android是linux内核的，而且能连网络，那么肯定是要端口来连接的，这是我的推测，没有去找相关的资料如果是手机的话，是不是会发条短信给手机，毕竟这样不需要知道IP之类的东西浏览器请求服务时，肯定是浏览器定时去服务器请求的，才可能知道有没有新的内容关于在Android手机端开放监听端口，我再研究一下，值得借鉴。问题补充：laorer 写道如果你是自己来管理这些的话，那么当用户连接到服务器时，你需要把用户的这些内容写到服务器的文本或者数据库或者直接保存到内存中，然后用户断开后，把相应的用户信息删掉这样当数据库有新消息时，你可以从保存用户信息的地方得到所有的连线用户，发消息给用户的话，就是把消息发给用户的IP和监听端口,如果客户端有http服务的话，你也可以直接发送http信息到这个客户端的http服务上这只是我的想法，你做个参考吧
iOS 系统的推送（APNS，即 Apple Push Notification Service）依托一个或几个系统常驻进程运作，是全局的（接管所有应用的消息推送），所以可看作是独立于应用之外，而且是设备和苹果服务器之间的通讯，而非应用的提供商服务器
所以， iOS 的推送，可以不严谨的理解为：苹果服务器朝手机后台挂的一个 IM 服务程序发送的消息。
然后，系统根据该 IM 消息识别告诉哪个 App 具体发生了什么事。
然后，系统分别通知这些 App
而 Android每个需要后台推送的应用有各自的单独后台进程，才能和各自的服务器通讯，交换数据。
其实 Android 也有类似 APNS 的 GCM（Google Cloud Message）的服务，如果一个应用的推送采用这种模式的话，就和iOS推送一个样了。
GCM相关的程序应该是集成在所谓的Gapps中，但国内的 Android 手机上 GCM 处于基本不可用的状态，而且Android 因为后台可以长驻，所以，App们各显神通。
聊天类应用的话，大多数直接借用 XMPP 规范里的一些成果。少量如微信有IM底子的，自己开发协议。这些在实现原理上与 APNs / GCM 没有本质的区别，但有一定的技术门槛。
而大多数普遍应用，要使用推送的话，则使用轮询的方式简单实现，就是定时去服务器上查询数据，也叫Polling，还有一种手机跟服务器之间维护一个 TCP 长连接，当服务器有数据时，实时推送到客户端，也就是我们说的 Push。
轮询的方式不论怎么优化都比较费电费流量，长连接的方式在网络不稳定的情况下，Socket比较容易断开推送数据失败，
安卓推送可以考虑使用第三方推送工具，比如极光推送
