科技新闻

Celery 是一个 基于python开发的分布式异步消息任务队列，通过它可以轻松的实现任务的异步处理， 如果你的业务场景中需要用到异步任务，就可以考虑使用celery， 举几个实例场景中可用的例子: 你想对100台机器执行一条批量命令，可能会花很长时间 ，但你不想让你的程序等着结果返回，而是给你返回 一个任务ID,你过一段时间只需要拿着这个任务id就可以拿到任务执行结果， 在任务执行ing进行时，你可以继续做其它的事情。 你想做一个定时任务，比如每天检测一下你们所有客户的资料，如果发现今天 是客户的生日，就给他发个短信祝福 Celery 在执行任务时需要通过一个消息中间件来接收和发送任务消息，以及存储任务结果， 一般使用rabbitMQ or Redis Celery有以下优点： 简单：一单熟悉了celery的工作流程后，配置和使用还是比较简单的 高可用：当任务执行失败或执行过程中发生连接中断，celery 会自动尝试重新执行任务 快速：一个单进程的celery每分钟可处理上百万个任务 灵活： 几乎celery的各个组件都可以被扩展及自定制 Celery基本工作流程图 Celery安装使用 Celery的默认broker是RabbitMQ, 仅需配置一行就可以 broker_url = 'amqp://guest:guest@localhost:5672//' rabbitMQ

前几日，同事收到很多异常报警，发现调用下游一个基础服务大量超时。经过讨论，为了防止服务宕机，我们把流量入口给拦住（我们的系统主要是处理上游推下来的Mq消息，就是将Mq消费入口给拦了）。我们还想着这样就能万事大吉应该不会产生脏数据。默默的等着下游系统解决问题。突然陆续收到服务宕机，7台核心业务服务器无一幸免全都挂了。 这时，我们想找出dump信息，看是不是jvm触发的，结果找了一圈都没有看到相关信息。既然，没有dump信息那肯定就不是JVM触发的kill（因为我们线上服务都开启异常自动dump堆栈的功能）。难道是内核因为内存不足触发的吗？触发日志在哪里可以看到呢？由于头次遇到，只能借助网上的力量，网上说输入 grep 'Out of memory' /var/log/messages。（其实就是在系统日志里面查看是不是能找到内存溢出的相关信息），果然有类似日志，如下图所示： 但是，日志也看不出来是什么原因导致的kill啊。想着上下翻动日志，看不懂。这个时候又只能借助网络。网上说内核触发了kill也可以通过 dmesg 命令查看（该命令是记录开机启动信息的）。通过现学，发现其实在上图的那条日志前面还保存了，内核kill进程之前的内存占用情况。如下图所示： 这是在图中找到了答案，系统总内存是8G，而filebeat（架构组的日志采集工具）占用2个多G，java进程占用4个多G

经过一段时间艰苦的奋斗，终于把sql server的读写分离搞定了。大家可以下载oneproxy-for-sqlserver来使用此功能。更多消息，可以访问 平民软件官网 获取。或者加入群 数据库监控 521095285 ，或者关注 oneproxy-monitor框架项目 （oneproxy-for-sqlserver是在此项目下开发的，会同步更新此框架） 下面说说oneproxy-for-sqlserver读写分离的使用方法和开发中遇到的有趣问题。 一. 使用方法 为了支持读写分离，需要修改[oneproxy]标签的数据和增加[database_xxx]标签的数据以及数据库组的信息。详细如下所示： 1) 在[oneproxy]标签下面增加：passwordseparate = true和readslave=true。增加后的配置如下所示： [oneproxy] logfile = oneproxy_log.log pidfile = oneproxy_pid.pid listen_addr = 0.0.0.0 listen_port = 9999,7777,6666 httpserver_addr = 0.0.0.0 httpserver_port = 8080 log_level = error data_dump = false log_sql = false

一、项目介绍 首先介绍下这个项目的大体流程，这是个接口程序，接收北向给的xml文件，然后转换为Document对象，然后把参数部分，按照指定的格式传递给南向接口。南向接口接收到消息以后，会做出处理，处理完以后，需要把返回的信息进行解析，解析后，在转换为Xml格式的文件，传递给北向接口。 需要做两个接口，一个接口是同步接口，另外一个接口是异步接口。同步接口接收信息后直接返回。异步接口需要回调北向给的接口方法，需要把参数先放到ActiveMQ中，然后再从MQ中取参数。 二、代码调试 最先使用myeclipse从SVN上下载代码，然后就直接开始使用了，发现好多jar包没有下载下来，然后就把maven引用删了，直接引入了所有的包。最后的结果告诉我，最好还是使用maven管理包，这样不会出现后期引用导致的包冲突。 因为程序是中间接口，首先要发布的webService可以连接北向。然后连接北向之后需要做的事情就是处理南向。其实现在调试通以后，觉得代码也比较熟悉。没有最开始那么费劲。 三、调试感受 其实代码量很小，但是调试两个周，主要原因是，调试前，业务不了解。代码比较混乱，看不清结构。 调试过后，重新整理了代码结构，感觉代码比较清晰，去掉了无用代码，感觉代码量少了很多。很多方法都没有使用，我都删了。。 感觉还是要静下心来做，不要觉得没啥意义，其实调试结束后，自己还是挺开心的，虽然过程很痛苦。

总结： 服务器状态在pubsub_channels字典保存了所有频道的订阅关系：SUBSCRIBE命令负责将客户端和被订阅的频道关联到这个字典里面，则UNSUBSCRIBE命令则负责解除客户端和退订频道之间 的关联。 服务器状态在pubsub_patterns链表保存了所有模式的订阅关系：PSUBSCRIBE命令负责将客户端 和被订阅的模式记录到这个链表中，而PUNSUBSCRIBE命令则负责移除客户端和被退订模式在链表中的记录。 PUBLISH 命令通过访问pubsub_channels字典来向频道的所有订阅者发送消息，通过访问 pubsub_patterns链表来向所有匹配频道的模式的订阅者发送消息。 PUBSUB命令的三个子命令都是通过读取pubsub_channels字典和pubsub_patterns链表中的信息来实现的。 订阅使用的场景是什么？？？？？ 补充： 消息系统该Push/Pull模式分析： http://blog.csdn.net/pi9nc/article/details/27714745 来源： oschina 链接： https://my.oschina.net/u/1475335/blog/682933

分布式消息队列 kafka介绍 基本架构 Kafka是开源的分布式消息队列，能够轻松实现高吞吐、可扩展、高可用，并且部署简单快速、开发接口丰富。 kafka分布式消息队列的作用： 解耦：将消息生产阶段和处理阶段拆分开，两个阶段互相独立各自实现自己的处理逻辑，通过kafka提供的消息写入和消费接口实现对消息的连接处理。降低开发复杂度，提高系统稳定性。 高吞吐量：kafka通过顺序读写磁盘提供可以和内存随机读写相匹敌的读写速度，灵活的客户端API设计，利用Linux操作系统提供的“零拷贝”特性减少消息网络传输时间，提供端到端的消息压缩传输，对同一主题下的消息采用分区存储，kafka通过诸多良好的特性利用廉价的机器就可以轻松实现高吞吐率。 高容错、高可用：kafka允许用户对分区配置多副本，kafka将副本均匀分配到各个broker存储，保证同一个分区的副本不会再同一台机器上存储（集群模式下），多副本之间采用Leader-Follower机制同步消息，只有Leader对外提供读写服务，当Leader以外失败、Broker进程关闭、服务宕机等情况导致数据不可用时，kafka会从Follwer中选择一个Leader继续提供读写服务。 可扩展：理论上kafka的性能随着Broker的增多而增加，增加一个Broker只需要为新增加的Broker设置一个唯一编号，编写好配置文件后

广播通知（ Toast Notifications ） 广播通知是在窗口表面弹出的一个消息。它只填充消息展现需要的空间，并且用户当前的 Activity 依然可见和可交互。通知自动的渐入渐出，不接受交互事件。 下面图1显示一个例子是闹钟应用的广播通知，一旦闹钟被打开，就会在你设置的提醒时间显示一个广播通知。 图1 广播通知能够由 Activity 或 Service 创建和显示。如果你创建了一个源自 Service 的广播通知，它会显示当前有焦点的 Activity 的前面。 如要需要用户对通知做出响应，请考虑使用状态栏通知。 基础 首先，用 makeText() 方法实例化一个 Toast 对象。这个方法需要三个参数： 1. 应用程序的 Context 对象； 2. 要显示的文本消息； 3. 通知持续表示的时间。这个方法会返回一个合适的被实例化的 Toast 对象。你能够用 show() 方法显示广播通知，显示方法如下： Context context = getApplicationContext (); CharSequence text = "Hello toast!" ; int duration = Toast . LENGTH_SHORT ; Toast toast = Toast . makeText ( context , text , duration );

大家好，今天给大家介绍下什么是数字中台；想必大家听到这个新词都有些不太理解或是有些蒙圈，其实我听到的时候也是不太理解，下面我给大家举例说明下： 1.数字中台，其实可以理解成中国移动10086接电话的客户人员，有咨询问题都可以问，客服人员接到需求之后会做需求分析和转发，也就说自己可以解决的问题，可以迅速反馈给客户，如果遇到难点就会转发到后端相关人员，也就是我们项目上经常说的相关方； 2.数字中台，也可以理解成已经定好的框架平台，就像腾讯云公网推出的移动金融开发平台一样，是一套成熟的解决方案，其实中台中有一个典型的功能模块就是消息推送功能，这个功能大家应该不太默认，就像大众用手机的时候打开某个网站的时候，经常会有优惠消息弹出，这就是中台中的消息推送功能； 3.数字中台，可以连接后端多个厂商，只需要在界面简单的配置下就可以完成，更加的人性化，简单化，稳定可靠； 4.数字中台，可以理解成就是我们北京的六里桥，客户站枢纽，连接着全国各地的市县； 5.中台连接着你我，连接着新时代的技术； 好了，今天就给大家介绍到这里了，后面我会把项目中的实战经验分享给大家，在项目实践中是如果遇到问题解决问题； 来源： 51CTO 作者： 柒年游 链接： https://blog.51cto.com/liwenming18/2477869

一、 广播域 广播是一种信息的传播方式，指网络中的某一设备同时向网络中所有的其它设备发送数据，这个数据所能广播到的范围即为广播域(Broadcast Domain)。 简单点说，广播域就是指网络中所有能接收到同样广播消息的设备的集合 隔离广播域：VLAN 路由器 VLAN(Virtual Local Area Network:虚拟局域网)在以太网帧中添加标签，计算机不识别标签 二、 VLAN划分 基于端口： 基于协议 基于Mac 基于IP 三、 VLAN接口类型 1.Access(接入) 主要用于 ： 终端连接交换机 标签的处理：接口收到以太网数据帧时打上标签，转发出端口时剥离标签（进打签出剥离） 配置命令 ：port link-type access Port default vlan xxx 2.Trunk 主要用于 ：主干连接 标签的处理：可以接收和发送多个VLAN的数据帧（设置允许通过），且在接收和发送过程中不对帧中的标签进行任何操作（trunk口的默认VLAN是个例外，trunk在发送帧时，trunk端口要剥离默认VLAN帧中的标签，同样，交换机从trunk接口接收到不带标签的帧时，要打上默认VLAN标签，） 配置命令：port link-type trunk Port trunk pvid vlan xxx port trunk allow-pass vlan xxx

文章目录 1进程间通信:管道 1进程间通信:管道 进程间通信 IPC: inter‐process communicating 两个进程之间互相交换数据，称为进程间通 信。 进程A 进程B 进程间通信 四种方式： ① 管道pipe ② 消息队列message queue ③ 共享内存shared memory ④ 网络套接字socket 管道 管道：pipe，是Linux操作系统提供的一个消息传递机制。 ① 系统中创建一个文件，其文件类型为管道 mkfifo ~/project/message ② 进程A: 打开open该文件，向文件写入write数据 ③ 进程B: 打开open该文件，从文件读取read数据 于是，数据 从进程A传递到进程B。。。显然，管道文件 并不是普通的文件。 管理文件不是普通的文件。。。 ls ‐l message prw‐rw‐r‐‐1 mytest mytest 0 8月 19 02:48 message (首字母为p，表示其类型为pipe) 演示 write.cpp : 向pipe中写入数据 read.cpp: 从pipe中读取数据 (1) open是阻塞的 一个发送方，一个接收方，都齐备时才返回 (2) read是阻塞的 (3) 管道是单向的 这意味着两个进程之间可能要建立两个管道 (4) 和普通文件 区别？？ 小结： 1，管道意义 2