① 外包管理人员怎么使用钉钉管理人员
考勤心得_基于钉钉考勤数据自动化处理的实践 原创
2021-01-12 04:22:33
兰小龙
码龄4年
关注
基于钉钉考勤数据自动化处理的实践
点击上方“技术支持联盟”，选择“置顶公众号”
第一时间了解程序员大小事儿
作者:冬日暖阳
摘要：随着公司业务拓展，科技赋能的推进，系统逐渐增多，相应外包公司及人员也在迅速扩充，人员管理问题日渐突出，为了能够更有效的管理外包人员，通过对接钉钉考勤信息，用数据了解部门中外包实际工作情况。
.png
01
痛点
厂商过多
外包厂商过多，无各个厂商单独钉钉情况，只有组内每月汇总，不好逐日逐周的追踪本组内外包厂商详情，从而及时调整组内外包人员工作积极性。
人员流动性大
外包人员流动性大，没有数据支撑，无法对人员个体及整体情况进行总结，通过数据从侧面了解外包工作时长、工作态度及工作能力，通过打卡详情数据，做到精确管理，典型追踪。
0 2
钉钉小程序创建
通过企业内部自建应用创建小程序：
.png
1.登录钉钉开发者后台。
说明：只有管理员和子管理员可登录开发者后台。
2.在应用开发页面，选择企业内部开发 > 小程序，然后单击创建应用。
.png
3.填写应用的基本信息，然后单击确定创建。 .png
4.在应用信息页面，单击开发管理，然后单击修改。
.png
5.根据以下信息配置开发信息，然后单击保存。
服务器出口IP：输入调用钉钉服务端API时使用的IP即企业服务器的公网IP，多个IP请以","隔开，支持带一个*号通配符的IP格式。
说明：同一个IP只能被一个企业使用。
6.管理后台地址(可选)：输入管理后台地址。
在钉钉管理后台-工作台-找到对应应用，点击应用图标，跳转到填写的地址。如设置为https://open.dingtalk.com/，登录钉钉管理后台，点击进入后如图所示。
.png
7.单击凭证与基础信息获取应用的AppKey和AppSecret。
.png
03
现阶段实现功能
日、周、月情况汇总，包含：
①外包厂商报备人员及打卡人员(含远程)对比，计算打卡率；
②汇总缺卡及缺勤人员详情及月度统计名单；
③汇总迟到人员(打卡时间9:30以后且前一天21:00之前打卡离场)及月度统计名单；
④工作时长统计：考勤打卡总时长、打卡人数、平均时长以及排名情况。
当日
.png
当月
.png
当周
.png
04
后续功能规划
1.覆盖范围由新一代组转为所有产品组
2.根据人力日常需要的信息调整规则，自动提供日、周、月数据，并发送邮件；
3.将考勤人员与外包管理系统人员进行统一关联管理
4.邮件板式调整，使整体更直观
历史文章
解决方案：
开源规则引擎--drools
redis基本原理介绍
spring-session集成redis问题
通过分析Nginx服务器日志统计用户流量并预警
加密与认证技术
【双十一钜惠：科技人的专属保障】移动端交互速度保证 ——影像上传优化
【双十一钜惠：科技人的专属保障】移动端认证保障 ——非对称加密及jwt应用
系统安全建设小经验
公共组件-需求自动录入TAPD
python初体验
HTML5实现自定义键盘及使用
Sentinel限流
基于公有云实时音视频通道的构建音视频组件方法与实战经验
分布式定时任务调度探讨
阿里云OSS javaAPI分享
Jmeter压测的使用
API接口安全优化浅谈
基于idea将传统应用maven化改造实践
安全漏洞预扫小工具
Nacos作为注册中心，配置中心部署方案
Rancher+K8S简化学习环境搭建方案
Excel大数据量解析优化方案
Sharding-JDBC个性化分表方案
基于JWT的接口权限认证
Spring Cloud Gateway实现限流
公网发布的通用技术解决方案
Nginx结合Lua实现限流
Mysql数据同步Canal方案
Weblogic部署基于Spring Cloud项目应用实例
智能验证码解析java语言实现
数据库的演绎与变迁-下架最后一台小型机
关于struts架构通过引入spring包实现bbo调用测试的未来式
架构系列：
双十一钜惠：科技人的专属保障】如何保障移动端活动的稳定运转？——移动端基础平台建设的经验分享
【双十一钜惠：一个有温度的技术公众号】科技人需要什么样的保障
架构师入门系列：架构三板斧“缓存，消息，异步”
监控&运维
redis监控工具-redislive
微服务链路追踪工具 Apache SkyWalking部署与实践
快速发现生产环境SQL问题
Grafana-业务数据监控实践
自动化运维能力提升
服务器监控及问题定位排除
基于Spring Boot Admin告警之应用状态告警
Ansible在自动化运维中的使用
自助迁发分支工具
大数据
浅谈大数据平台的建设
基于CDH集群的大数据项目的优化总结
Oracle实时同步大数据平台解决方案
实时流关联维表解决方案
中间件
浅谈Elasticsearch的资源分配
Apache Kafka使用规范Elasticsearch安装及使用
SSDB介绍及使用
RabbitMq使用简单介绍
Spring Cloud常用组件介绍
前端
ESLint + Prettier 规范前端代码
Vue.js对WinXP系统对兼容性
关于采集操作系统、浏览器版本的设计方案及一些浏览器兼容性问题处理
安卓动态加载SO文件
对浏览器的理解及兼容移动端H5本地化方案调研和实践
自适应网页设计
短信/浏览器唤起APP方案
基础知识
Sonar简介
JVM基础系列1：JVM内存模型介绍
JVM基础系列2：JVM配置参数和Java内存模型
JVM基础系列3 虚拟机字节码执行引擎
开发规范
Java异常处理规范
战略方向
金融保险系统开源浪潮下机遇与挑战
项目实战
《Scrum精髓》心得分享
聊一聊我们程序猿--技术交流感悟分享
如何快速支撑健康险业务发展
《凤凰项目-一个IT运维传奇故事》心得分享
运维工作要学会“偷懒”
“用户思维+中台架构”快速搭建金融宝app
多维分保的应用探索
用文化指引自身的成长之路 -2020年技术成长心得分享
从工作中探寻自身的成长之路
从《平凡的荣耀》到记一次兼容性改造优化后的技术感悟
客户为中心，统筹协调，把控风险
让我们的管理看的见
.png E N D
.gif
请识别下方二维码，关注 技术支持联盟.png
欢迎加入基于钉钉API功能开发交流，请扫码进群
.png
AppKey
打开CSDN APP，看更多技术内容
钉钉开发DEMO
此程序为钉钉应用，亲测可以用，非喜勿喷，有任何疑问可以私信，互相交流
同步考勤数据 钉钉_钉钉考勤打卡攻略①
钉钉考勤打卡是专门针对企业员工上下班打卡的一款考勤应用。考勤打卡应用可以让人事随时随地了解团队状态，出勤人员一目了然；智能统计考勤数据，云端存储，考勤数据永不丢失哦[灵光一闪]一、如何新增考勤组？手机端：点击【工作台】—【考勤】—【设置】—【新建考勤组】电脑端：登录管理后台—【工作台】—【考勤打卡】—【考勤组管理】—【新建考勤组】二、考勤组如何添加人？手机端：点击【工作台】—【考勤打卡】—【设置】...
继续访问
钉钉考勤数据抓取_VBA实战篇|HR们的福利，从此不再为整理考勤记录发狂
提示：这是7月的第1篇原创文章关于整理‘考勤记录’的案例如果你喜欢本文，就分享给你的小伙伴，你的喜欢是我前进的最大动力如果你有任何疑问，可以文章下方留言或后台留言在HR的日常工作中，统计考勤是其中一项工作。虽然现在有考勤机、钉钉等高科技的手段进行辅助，但是有些考勤机导出的数据会让各位HR们集体吐槽为何如此反人类的设计。如下图所示，是我一位HR朋友发我的考勤记录(数据已做部分处理)，看到这...
继续访问
钉钉API考勤打卡记录获取并存入数据库（python）
前言： 钉钉有个开发平台，通过API可以开发自己企业内部应用，钉钉开发文档顺序写的有点乱，花了挺长时间才看懂，我写了一个python脚本来获取考勤记录，当然能做的不止这些，可以删除公司成员，修改部门，瞎发通知等等。。。（这是上路的新手，大神忽略。） 一、准备 钉钉API地址：https://open-doc.dingtalk.com/docs/doc.htm?spm=0.0....
继续访问
钉钉考勤接口调用与OA系统数据对接
钉钉考勤接口调用与OA系统数据对接 公司由原来的指纹打卡更换为钉钉打卡，需要钉钉和现有的OA考勤数据对接（合并钉钉打卡数据和OA上的请假，外出，出差数据） 1.查看钉钉接口文档 https://ding-doc.dingtalk.com/doc#/serverapi2/gh60vz 2.项目搭建引入钉钉开发SDK 3.获取钉钉考勤数据存储服务器数据库（调整存储格式） //测试 public s...
继续访问
最新发布 从钉钉后台获取考勤数据（其他数据获取类似）
从钉钉后台获取数据
继续访问
钉钉考勤数据抓取_员工考勤管理系统：如何轻松计算出每月的考勤数据
其实想要达到你这种效果的话有两种方法： 一个是使用考勤机 一个是使用员工考勤管理系统考勤机 一般的企业为了加强自己的考勤管理，使用比较多的就是指纹打卡考勤机，只要上下班的时候通过指纹打卡就行了。优点： 费用低几百到几千就能搞定，适合人数不太多的中小企业，只要在需要整理数据的时候把数据导出到电脑里就行。缺点： 没法儿自动帮你汇总分析，导出来的数据只是作为记录，如果你要计算或者和绩效结合的话，需...
继续访问
钉钉考勤数据抓取_钉钉考勤答疑你关心的都在这里
钉钉/// ///那些事儿///答疑篇 ///为提高工作效率，公司引进钉钉考勤系统替代传统打卡模式，经过一个月的使用，经过前期对数据的分析整理，现将钉钉使用过程中遇到的一些疑惑进行解答。首先请各部门确认所有人员都在“浙江新和成股份有限公司钉钉考勤组”，如果有新员工不在该群组的，部门考勤员要先将人员邀请进考勤组。01.钉钉数据是如何采集的？ ...
继续访问
钉钉API考勤打卡记录获取(php + JS)
前言： 钉钉有个开发平台，通过API可以开发自己企业内部应用，钉钉开发文档顺序写的有点乱，花了挺长时间才看懂，我建立一个php后端以及一个单独网页（不运行在钉钉上）来获取考勤记录，当然能做的不止这些，可以删除公司成员，修改部门，瞎发通知等等。。。（这是上路的新手，大神忽略，练习下AJAX倒是挺好的。） 一、准备 钉钉API地址： https://open-doc.dingtalk.co...
继续访问
热门推荐 获取钉钉考勤机的打卡记录并且解析
有个特别恶心的地方就是打卡信息只能最多一次取七天的。所以要注意一下； 时间格式：2018-05-01 钉钉突然改接口了，直接获取是被拒绝了，加了分页限制，加了人数限制，头大，之前得方法不能用了，重新写了版，最多一次获取50个人的考勤，并且这些人的考勤记录一次只能获取50条，我想了个办法中心思想就是首先拆分公司人员的dingId的列表，拆成每50个一组，然后限制分页最大50个每页，50个人的打...
继续访问
钉钉考勤数据抓取_华跃考勤管理系统
华跃考勤管理系统通过我司考勤系统把人力资源管理重要环节做到及时管控，随时可分析员工日出勤异常报表、周出勤、月出勤等出勤数据。软件兼容先进的现代感应式、RFID、指纹、图像管理等硬件设备，在防止代打卡和混加班等方面有独到的实施经验。可满足不同企业的各种考勤制度，客户自定义的设计使不同行业的用户可根据其所制定的考勤制度对系统进行灵活设置。智能排班的自动抓取让您对排班无需进行任何操作，班次采用...
继续访问
积分-钉钉考勤-取参与考勤人员
钉钉考勤接口调用与OA系统数据对接（多线程版）
钉钉考勤接口调用与OA系统数据对接（多线程版） 公司由原来的指纹打卡更换为钉钉打卡，需要钉钉和现有的OA考勤数据对接（合并钉钉打卡数据和OA上的请假，外出，出差数据），因为人数增减单线程定时任务数据抓取时间较长，做一下优化 1.线程池 class CountableThreadPool { private int threadNum; private AtomicInteger...
继续访问
从钉钉后台对接考勤打卡信息（仅供参考）
# -*- coding: utf-8 -*- import requests, logging, json, openpyxl, os, time #官方下载SDK import dingtalk.api from datetime import datetime as dt from datetime import timedelta import xlsxwriter import configparser import datetime logging.basicConfig(level=logg
继续访问
dingtalk 一个让钉钉服务端开发更简单的golang工具库
dingtalk 这是一个集成钉钉常用功能的简易版服务端开发工具库,适用于创建一次客户端，多次调用的场景。内置token过期时间维护；内置用户id到用户userid的计算函数，可以方便的在企业用户名与userid之间自动转换；同时在rece函数中可以设置加入白名单过滤，避免在测试环境中发信息给非白名单用户。具体参数说明，请参考钉钉开发文档 仓库地址 https://github.com/kevin2027/easy-dingtalk 安装 go get -u github.com/kevin2027
继续访问
【钉钉-场景化能力包】制造业考勤数据多维分析
企业结合钉钉考勤的能力后，可以获取钉钉的考勤数据，并将考勤数据从时间、机构、部门、人员等多个维度进行横向纵向比对分析，从而了解一段时间内企业考勤情况的变化趋势以及各个部门在提升考勤率方面的成果对比，并通过宣导、鼓励和问责等方式进一步提升员工的工作效能，逐步提升企业整体的考勤达成率。
继续访问
② ios app压力测试工具有哪些
开发和压力测试软件大全：
ShareSDK
功能强大、简单易用的iOS app开发必备社会化分享类库：ShareSDK。iOS app开发者只需10分钟即可集成到自己的APP中。不仅支持如QQ、微信、新浪微博、腾讯微博、人人网、豆瓣、facebook、twitter等国内外主流社交平台，还有强大的统计分析管理后台，可以实时了解用户、信息流、回流率等数据。
iOS加密
iOS app开发必备加密技术，全球独有，针对iOS app开发的技术原理和破解原理，分别从本地数据、方法体/方法名、URL编码、程序结构、网络传输数据等几个方面对iOS app开发进行全方位的保护，从而实现iOS app防破解保护。
Tui
iOS app开发必备，基于FlashCS6的cocos2d-x UI编辑器，可用于操作系统：Mac OS,Windows
PonyDebugger
iOS app开发必备网络调试工具，用于操作系统：Mac OS,其他Pony Debugger 是一个iOS app开发必备的远程调试工具包，通过使用 Chrome 开发者工具来调试 iOS app开发的网络流量和数据存储。
iTestin
iTestin是免费服务iOS app开发者的真机自动化云测试客户端iOS app开发工具。基于真实的智能终端设备录制一个测试脚本然后运行，并输出运行结果。支持功能测试、UI测试、性能测试、稳定性测试、压力测试，返回包括日志和截图的详细测试报告。
Cornerstone
Mac上最佳的SVN管理iOS app开发必备工具，可用于的用于操作系统包括Mac OS
CocosBuilder
最牛iOS app开发必备Cocos2d编辑器，Mac专属，对于开发iOS app，Cocos2d-iPhone引擎做的2D游戏开发者来说最大的福音
MarkMan
MarkMan是一款iOS app开发必备高效的设计稿标注和测量软件，用于操作系统：Mac OS,Windows
SQLCipher
SQLite加密，iOS app开发必备，SQLCipher 提供了对 SQLite 数据库的传输层进行全面加密的iOS app开发工具。而通过使用 SQLCipher ，整个加密过程对客户端是透明的，无需改动应用程序。
③ 对于一个视频会议软件要如何测试，怎样进行压力测试呢
让员工在不同的环境下分阶段进入会议，人数逐渐增加，最后测试各种功能即可。
视频会议软件选择中目视频会议软件。
中目视频会议软件具有以下优势：
1.高清视频和音频：将高质量视频、音频和网络会议带入任何大小的会议室中。
2.与任何人召开会议：在台式机、手机或其他会议室系统上加入远程参与者。
3.单触启动会议：使用语音命令或单触启动即时会议或会议通过你的日历系统。
4.与H.323协议的互操作性：与任何传统的端点，包括宝利通，思科和LifeSize。
中目视频会议软件操作简单无论何时何地，不受终端限制，一键加入会议，一键发起会议。同时支持文件共享、注释等协同操作。同声传译、美颜、满足各种需求。还支持万人超大规模会议。不受行业限制，多场景应用。高标准加密，数据更安全。支持私有云部署，让安全更有保障，售后提供一对一服务，出现问题及时解决，产品种类多，满足各种高阶需求。
中目视频会议软件是华万旗下的一款产品。
上海华万通信科技有限公司，2013年成立于上海，是业内知名的通信云产品运营商。拥有工信部(中华人民共和国工业和信息化部)颁发的全国多方通信运营牌照。
华万通信自成立以来，始终秉持向客户提供优质的产品和服务为己任，以“创新研发驱动公司发展”为基本方针，已形成通信云产品及云通信智能硬件两大业务板块。通过不断发展，定位聚焦“华万品牌，华万研发”，为近万家政企及教育行业的客户提供优质的通信云产品及服务，致力让每个组织享有高效快捷的智能云通信产品及服务。
④ 如何实现支持数亿用户的长连消息系统
此文是根据周洋在【高可用架构群】中的分享内容整理而成，转发请注明出处。
周洋，360手机助手技术经理及架构师，负责360长连接消息系统，360手机助手架构的开发与维护。
不知道咱们群名什么时候改为“Python高可用架构群”了，所以不得不说，很荣幸能在接下来的一个小时里在Python群里讨论golang....
360消息系统介绍
360消息系统更确切的说是长连接push系统，目前服务于360内部多个产品，开发平台数千款app，也支持部分聊天业务场景，单通道多app复用，支持上行数据，提供接入方不同粒度的上行数据和用户状态回调服务。
目前整个系统按不同业务分成9个功能完整的集群，部署在多个idc上（每个集群覆盖不同的idc），实时在线数亿量级。通常情况下，pc，手机，甚至是智能硬件上的360产品的push消息，基本上是从我们系统发出的。
关于push系统对比与性能指标的讨论
很多同行比较关心go语言在实现push系统上的性能问题，单机性能究竟如何，能否和其他语言实现的类似系统做对比么？甚至问如果是创业,第三方云推送平台，推荐哪个?
其实各大厂都有类似的push系统，市场上也有类似功能的云服务。包括我们公司早期也有erlang，nodejs实现的类似系统，也一度被公司要求做类似的对比测试。我感觉在讨论对比数据的时候，很难保证大家环境和需求的统一，我只能说下我这里的体会，数据是有的，但这个数据前面估计会有很多定语~
第一个重要指标：单机的连接数指标
做过长连接的同行，应该有体会，如果在稳定连接情况下，连接数这个指标，在没有网络吞吐情况下对比，其实意义往往不大，维持连接消耗cpu资源很小，每条连接tcp协议栈会占约4k的内存开销，系统参数调整后，我们单机测试数据，最高也是可以达到单实例300w长连接。但做更高的测试，我个人感觉意义不大。
因为实际网络环境下，单实例300w长连接，从理论上算压力就很大：实际弱网络环境下，移动客户端的断线率很高，假设每秒有1000分之一的用户断线重连。300w长连接，每秒新建连接达到3w，这同时连入的3w用户，要进行注册，加载离线存储等对内rpc调用，另外300w长连接的用户心跳需要维持,假设心跳300s一次，心跳包每秒需要1w tps。单播和多播数据的转发，广播数据的转发，本身也要响应内部的rpc调用，300w长连接情况下，gc带来的压力，内部接口的响应延迟能否稳定保障。这些集中在一个实例中，可用性是一个挑战。所以线上单实例不会hold很高的长连接,实际情况也要根据接入客户端网络状况来决定。
第二个重要指标:消息系统的内存使用量指标
这一点上，使用go语言情况下，由于协程的原因，会有一部分额外开销。但是要做两个推送系统的对比，也有些需要确定问题。比如系统从设计上是否需要全双工（即读写是否需要同时进行）如果半双工，理论上对一个用户的连接只需要使用一个协程即可（这种情况下，对用户的断线检测可能会有延时），如果是全双工，那读/写各一个协程。两种场景内存开销是有区别的。
另外测试数据的大小往往决定我们对连接上设置的读写buffer是多大，是全局复用的，还是每个连接上独享的，还是动态申请的。另外是否全双工也决定buffer怎么开。不同的策略，可能在不同情况的测试中表现不一样。
第三个重要指标：每秒消息下发量
这一点上，也要看我们对消息到达的QoS级别(回复ack策略区别），另外看架构策略，每种策略有其更适用的场景，是纯粹推？还是推拉结合？甚至是否开启了消息日志？日志库的实现机制、以及缓冲开多大？flush策略……这些都影响整个系统的吞吐量。
另外为了HA，增加了内部通信成本，为了避免一些小概率事件，提供闪断补偿策略，这些都要考虑进去。如果所有的都去掉，那就是比较基础库的性能了。
所以我只能给出大概数据，24核，64G的服务器上，在QoS为message at least，纯粹推，消息体256B~1kB情况下，单个实例100w实际用户（200w+）协程，峰值可以达到2~5w的QPS...内存可以稳定在25G左右，gc时间在200~800ms左右（还有优化空间）。
我们正常线上单实例用户控制在80w以内，单机最多两个实例。事实上，整个系统在推送的需求上，对高峰的输出不是提速，往往是进行限速，以防push系统瞬时的高吞吐量，转化成对接入方业务服务器的ddos攻击所以对于性能上，我感觉大家可以放心使用，至少在我们这个量级上，经受过考验，go1.5到来后，确实有之前投资又增值了的感觉。
消息系统架构介绍
下面是对消息系统的大概介绍，之前一些同学可能在gopher china上可以看到分享，这里简单讲解下架构和各个组件功能，额外补充一些当时遗漏的信息：
架构图如下，所有的service都 written by golang.
几个大概重要组件介绍如下：
dispatcher service根据客户端请求信息，将应网络和区域的长连接服务器的，一组IP传送给客户端。客户端根据返回的IP，建立长连接，连接Room service.
room Service，长连接网关，hold用户连接，并将用户注册进register service，本身也做一些接入安全策略、白名单、IP限制等。
register service是我们全局session存储组件，存储和索引用户的相关信息，以供获取和查询。
coordinator service用来转发用户的上行数据，包括接入方订阅的用户状态信息的回调，另外做需要协调各个组件的异步操作，比如kick用户操作,需要从register拿出其他用户做异步操作.
saver service是存储访问层，承担了对redis和mysql的操作，另外也提供部分业务逻辑相关的内存缓存，比如广播信息的加载可以在saver中进行缓存。另外一些策略，比如客户端sdk由于被恶意或者意外修改，每次加载了消息，不回复ack，那服务端就不会删除消息，消息就会被反复加载，形成死循环，可以通过在saver中做策略和判断。（客户端总是不可信的）。
center service提供给接入方的内部api服务器，比如单播或者广播接口，状态查询接口等一系列api,包括运维和管理的api。
举两个常见例子，了解工作机制：比如发一条单播给一个用户，center先请求Register获取这个用户之前注册的连接通道标识、room实例地址，通过room service下发给长连接 Center Service比较重的工作如全网广播，需要把所有的任务分解成一系列的子任务，分发给所有center，然后在所有的子任务里，分别获取在线和离线的所有用户，再批量推到Room Service。通常整个集群在那一瞬间压力很大。
deployd/agent service用于部署管理各个进程，收集各组件的状态和信息,zookeeper和keeper用于整个系统的配置文件管理和简单调度
关于推送的服务端架构
常见的推送模型有长轮训拉取，服务端直接推送（360消息系统目前主要是这种），推拉结合（推送只发通知，推送后根据通知去拉取消息）.
拉取的方式不说了，现在并不常用了，早期很多是nginx+lua+redis，长轮训，主要问题是开销比较大，时效性也不好，能做的优化策略不多。
直接推送的系统，目前就是360消息系统这种，消息类型是消耗型的，并且对于同一个用户并不允许重复消耗,如果需要多终端重复消耗，需要抽象成不同用户。
推的好处是实时性好，开销小，直接将消息下发给客户端，不需要客户端走从接入层到存储层主动拉取.
但纯推送模型，有个很大问题，由于系统是异步的，他的时序性无法精确保证。这对于push需求来说是够用的，但如果复用推送系统做im类型通信，可能并不合适。
对于严格要求时序性，消息可以重复消耗的系统，目前也都是走推拉结合的模型，就是只使用我们的推送系统发通知，并附带id等给客户端做拉取的判断策略，客户端根据推送的key，主动从业务服务器拉取消息。并且当主从同步延迟的时候，跟进推送的key做延迟拉取策略。同时也可以通过消息本身的QoS，做纯粹的推送策略，比如一些“正在打字的”低优先级消息，不需要主动拉取了，通过推送直接消耗掉。
哪些因素决定推送系统的效果？
首先是sdk的完善程度，sdk策略和细节完善度，往往决定了弱网络环境下最终推送质量.
SDK选路策略,最基本的一些策略如下：有些开源服务可能会针对用户hash一个该接入区域的固定ip，实际上在国内环境下不可行，最好分配器（dispatcher）是返回散列的一组，而且端口也要参开，必要时候，客户端告知是retry多组都连不上，返回不同idc的服务器。因为我们会经常检测到一些case，同一地区的不同用户，可能对同一idc内的不同ip连通性都不一样，也出现过同一ip不同端口连通性不同，所以用户的选路策略一定要灵活，策略要足够完善.另外在选路过程中，客户端要对不同网络情况下的长连接ip做缓存，当网络环境切换时候（wifi、2G、3G)，重新请求分配器，缓存不同网络环境的长连接ip。
客户端对于数据心跳和读写超时设置,完善断线检测重连机制
针对不同网络环境，或者客户端本身消息的活跃程度，心跳要自适应的进行调整并与服务端协商，来保证链路的连通性。并且在弱网络环境下，除了网络切换（wifi切3G）或者读写出错情况，什么时候重新建立链路也是一个问题。客户端发出的ping包，不同网络下，多久没有得到响应，认为网络出现问题，重新建立链路需要有个权衡。另外对于不同网络环境下，读取不同的消息长度，也要有不同的容忍时间，不能一刀切。好的心跳和读写超时设置，可以让客户端最快的检测到网络问题，重新建立链路，同时在网络抖动情况下也能完成大数据传输。
结合服务端做策略
另外系统可能结合服务端做一些特殊的策略，比如我们在选路时候，我们会将同一个用户尽量映射到同一个room service实例上。断线时，客户端尽量对上次连接成功的地址进行重试。主要是方便服务端做闪断情况下策略，会暂存用户闪断时实例上的信息，重新连入的 时候，做单实例内的迁移，减少延时与加载开销.
客户端保活策略
很多创业公司愿意重新搭建一套push系统，确实不难实现，其实在协议完备情况下（最简单就是客户端不回ack不清数据），服务端会保证消息是不丢的。但问题是为什么在消息有效期内,到达率上不去？往往因为自己app的push service存活能力不高。选用云平台或者大厂的，往往sdk会做一些保活策略，比如和其他app共生，互相唤醒，这也是云平台的push service更有保障原因。我相信很多云平台旗下的sdk，多个使用同样sdk的app，为了实现服务存活，是可以互相唤醒和保证活跃的。另外现在push sdk本身是单连接，多app复用的，这为sdk实现，增加了新的挑战。
综上，对我来说，选择推送平台，优先会考虑客户端sdk的完善程度。对于服务端，选择条件稍微简单，要求部署接入点（IDC）越要多，配合精细的选路策略，效果越有保证，至于想知道哪些云服务有多少点，这个群里来自各地的小伙伴们，可以合伙测测。
go语言开发问题与解决方案
下面讲下，go开发过程中遇到挑战和优化策略，给大家看下当年的一张图，在第一版优化方案上线前一天截图~
可以看到，内存最高占用69G，GC时间单实例最高时候高达3~6s.这种情况下，试想一次悲剧的请求，经过了几个正在执行gc的组件，后果必然是超时... gc照成的接入方重试，又加重了系统的负担。遇到这种情况当时整个系统最差情况每隔2，3天就需要重启一次~
当时出现问题，现在总结起来，大概以下几点
1.散落在协程里的I/O，Buffer和对象不复用。
当时（12年）由于对go的gc效率理解有限，比较奔放，程序里大量short live的协程，对内通信的很多io操作，由于不想阻塞主循环逻辑或者需要及时响应的逻辑，通过单独go协程来实现异步。这回会gc带来很多负担。
针对这个问题，应尽量控制协程创建，对于长连接这种应用，本身已经有几百万并发协程情况下，很多情况没必要在各个并发协程内部做异步io，因为程序的并行度是有限，理论上做协程内做阻塞操作是没问题。
如果有些需要异步执行，比如如果不异步执行，影响对用户心跳或者等待response无法响应，最好通过一个任务池，和一组常驻协程，来消耗，处理结果，通过channel再传回调用方。使用任务池还有额外的好处，可以对请求进行打包处理，提高吞吐量，并且可以加入控量策略.
2.网络环境不好引起激增
go协程相比较以往高并发程序，如果做不好流控，会引起协程数量激增。早期的时候也会发现，时不时有部分主机内存会远远大于其他服务器，但发现时候，所有主要profiling参数都正常了。
后来发现，通信较多系统中，网络抖动阻塞是不可免的(即使是内网)，对外不停accept接受新请求，但执行过程中，由于对内通信阻塞，大量协程被 创建，业务协程等待通信结果没有释放，往往瞬时会迎来协程暴涨。但这些内存在系统稳定后，virt和res都并没能彻底释放，下降后，维持高位。
处理这种情况，需要增加一些流控策略，流控策略可以选择在rpc库来做，或者上面说的任务池来做，其实我感觉放在任务池里做更合理些，毕竟rpc通信库可以做读写数据的限流，但它并不清楚具体的限流策略，到底是重试还是日志还是缓存到指定队列。任务池本身就是业务逻辑相关的，它清楚针对不同的接口需要的流控限制策略。
3.低效和开销大的rpc框架
早期rpc通信框架比较简单，对内通信时候使用的也是短连接。这本来短连接开销和性能瓶颈超出我们预期，短连接io效率是低一些，但端口资源够，本身吞吐可以满足需要，用是没问题的，很多分层的系统，也有http短连接对内进行请求的
但早期go版本，这样写程序，在一定量级情况，是支撑不住的。短连接大量临时对象和临时buffer创建，在本已经百万协程的程序中，是无法承受的。所以后续我们对我们的rpc框架作了两次调整。
第二版的rpc框架，使用了连接池，通过长连接对内进行通信（复用的资源包括client和server的：编解码Buffer、Request/response），大大改善了性能。
但这种在一次request和response还是占用连接的，如果网络状况ok情况下，这不是问题，足够满足需要了，但试想一个room实例要与后面的数百个的register，coordinator，saver，center，keeper实例进行通信，需要建立大量的常驻连接，每个目标机几十个连接，也有数千个连接被占用。
非持续抖动时候（持续逗开多少无解），或者有延迟较高的请求时候，如果针对目标ip连接开少了，会有瞬时大量请求阻塞，连接无法得到充分利用。第三版增加了Pipeline操作，Pipeline会带来一些额外的开销，利用tcp的全双特性，以尽量少的连接完成对各个服务集群的rpc调用。
4.Gc时间过长
Go的Gc仍旧在持续改善中，大量对象和buffer创建，仍旧会给gc带来很大负担，尤其一个占用了25G左右的程序。之前go team的大咖邮件也告知我们，未来会让使用协程的成本更低，理论上不需要在应用层做更多的策略来缓解gc.
改善方式，一种是多实例的拆分，如果公司没有端口限制，可以很快部署大量实例，减少gc时长，最直接方法。不过对于360来说，外网通常只能使用80和433。因此常规上只能开启两个实例。当然很多人给我建议能否使用SO_REUSEPORT，不过我们内核版本确实比较低，并没有实践过。
另外能否模仿nginx，fork多个进程监控同样端口，至少我们目前没有这样做，主要对于我们目前进程管理上，还是独立的运行的，对外监听不同端口程序，还有配套的内部通信和管理端口，实例管理和升级上要做调整。
解决gc的另两个手段，是内存池和对象池,不过最好做仔细评估和测试，内存池、对象池使用，也需要对于代码可读性与整体效率进行权衡。
这种程序一定情况下会降低并行度，因为用池内资源一定要加互斥锁或者原子操作做CAS，通常原子操作实测要更快一些。CAS可以理解为可操作的更细行为粒度的锁（可以做更多CAS策略，放弃运行，防止忙等）。这种方式带来的问题是，程序的可读性会越来越像C语言，每次要malloc，各地方用完后要free，对于对象池free之前要reset，我曾经在应用层尝试做了一个分层次结构的“无锁队列”
上图左边的数组实际上是一个列表，这个列表按大小将内存分块，然后使用atomic操作进行CAS。但实际要看测试数据了，池技术可以明显减少临时对象和内存的申请和释放，gc时间会减少，但加锁带来的并行度的降低，是否能给一段时间内的整体吞吐量带来提升，要做测试和权衡…
在我们消息系统，实际上后续去除了部分这种黑科技，试想在百万个协程里面做自旋操作申请复用的buffer和对象，开销会很大，尤其在协程对线程多对多模型情况下，更依赖于golang本身调度策略，除非我对池增加更多的策略处理，减少忙等，感觉是在把runtime做的事情，在应用层非常不优雅的实现。普遍使用开销理论就大于收益。
但对于rpc库或者codec库，任务池内部，这些开定量协程，集中处理数据的区域，可以尝试改造~
对于有些固定对象复用，比如固定的心跳包什么的，可以考虑使用全局一些对象，进行复用，针对应用层数据，具体设计对象池，在部分环节去复用，可能比这种无差别的设计一个通用池更能进行效果评估.
消息系统的运维及测试
下面介绍消息系统的架构迭代和一些迭代经验，由于之前在其他地方有过分享，后面的会给出相关链接，下面实际做个简单介绍，感兴趣可以去链接里面看
架构迭代~根据业务和集群的拆分，能解决部分灰度部署上线测试，减少点对点通信和广播通信不同产品的相互影响，针对特定的功能做独立的优化.
消息系统架构和集群拆分，最基本的是拆分多实例，其次是按照业务类型对资源占用情况分类，按用户接入网络和对idc布点要求分类（目前没有条件，所有的产品都部署到全部idc）
系统的测试go语言在并发测试上有独特优势。
对于压力测试，目前主要针对指定的服务器，选定线上空闲的服务器做长连接压测。然后结合可视化，分析压测过程中的系统状态。但压测早期用的比较多，但实现的统计报表功能和我理想有一定差距。我觉得最近出的golang开源产品都符合这种场景，go写网络并发程序给大家带来的便利，让大家把以往为了降低复杂度，拆解或者分层协作的组件，又组合在了一起。
Q&A
Q1:协议栈大小，超时时间定制原则？
移动网络下超时时间按产品需求通常2g，3G情况下是5分钟，wifi情况下5~8分钟。但对于个别场景，要求响应非常迅速的场景，如果连接idle超过1分钟，都会有ping，pong，来校验是否断线检测，尽快做到重新连接。
Q2:消息是否持久化？
消息持久化，通常是先存后发，存储用的redis，但落地用的mysql。mysql只做故障恢复使用。
Q3:消息风暴怎么解决的？
如果是发送情况下，普通产品是不需要限速的，对于较大产品是有发送队列做控速度，按人数，按秒进行控速度发放，发送成功再发送下一条。
Q4:golang的工具链支持怎么样？我自己写过一些小程序千把行之内，确实很不错，但不知道代码量上去之后，配套的debug工具和profiling工具如何，我看上边有分享说golang自带的profiling工具还不错，那debug呢怎么样呢，官方一直没有出debug工具，gdb支持也不完善，不知你们用的什么？
是这样的，我们正常就是println，我感觉基本上可以定位我所有问题，但也不排除由于并行性通过println无法复现的问题，目前来看只能靠经验了。只要常见并发尝试，经过分析是可以找到的。go很快会推出调试工具的~
Q5:协议栈是基于tcp吗？
是否有协议拓展功能？协议栈是tcp，整个系统tcp长连接，没有考虑扩展其功能~如果有好的经验，可以分享~
Q6:问个问题，这个系统是接收上行数据的吧，系统接收上行数据后是转发给相应系统做处理么，是怎么转发呢，如果需要给客户端返回调用结果又是怎么处理呢？
系统上行数据是根据协议头进行转发，协议头里面标记了产品和转发类型，在coordinator里面跟进产品和转发类型，回调用户，如果用户需要阻塞等待回复才能后续操作，那通过再发送消息，路由回用户。因为整个系统是全异步的。
Q7:问个pushsdk的问题。pushsdk的单连接，多app复用方式，这样的情况下以下几个问题是如何解决的：1）系统流量统计会把所有流量都算到启动连接的应用吧？而启动应用的连接是不固定的吧？2）同一个pushsdk在不同的应用中的版本号可能不一样，这样暴露出来的接口可能有版本问题，如果用单连接模式怎么解决？
流量只能算在启动的app上了，但一般这种安装率很高的app承担可能性大，常用app本身被检测和杀死可能性较少，另外消息下发量是有严格控制 的。整体上用户还是省电和省流量的。我们pushsdk尽量向上兼容，出于这个目的，push sdk本身做的工作非常有限，抽象出来一些常见的功能，纯推的系统，客户端策略目前做的很少，也有这个原因。
Q8:生产系统的profiling是一直打开的么？
不是一直打开，每个集群都有采样，但需要开启哪个可以后台控制。这个profling是通过接口调用。
Q9:面前系统中的消息消费者可不可以分组？类似于Kafka。
客户端可以订阅不同产品的消息，接受不同的分组。接入的时候进行bind或者unbind操作
Q10:为什么放弃erlang,而选择go，有什么特别原因吗？我们现在用的erlang？
erlang没有问题，原因是我们上线后，其他团队才做出来，经过qa一个部门对比测试，在没有显着性能提升下，选择继续使用go版本的push，作为公司基础服务。
Q11:流控问题有排查过网卡配置导致的idle问题吗？
流控是业务级别的流控，我们上线前对于内网的极限通信量做了测试，后续将请求在rpc库内，控制在小于内部通信开销的上限以下.在到达上限前作流控。
Q12:服务的协调调度为什么选择zk有考虑过raft实现吗？golang的raft实现很多啊，比如Consul和ectd之类的。
3年前，还没有后两者或者后两者没听过应该。zk当时公司内部成熟方案，不过目前来看，我们不准备用zk作结合系统的定制开发，准备用自己写的keeper代替zk，完成配置文件自动转数据结构，数据结构自动同步指定进程，同时里面可以完成很多自定义的发现和控制策略，客户端包含keeper的sdk就可以实现以上的所有监控数据，profling数据收集，配置文件更新，启动关闭等回调。完全抽象成语keeper通信sdk，keeper之间考虑用raft。
Q13:负载策略是否同时在服务侧与CLIENT侧同时做的 (DISPATCHER 会返回一组IP)？另外，ROOM SERVER/REGISTER SERVER连接状态的一致性|可用性如何保证? 服务侧保活有无特别关注的地方? 安全性方面是基于TLS再加上应用层加密?
会在server端做，比如重启操作前，会下发指令类型消息，让客户端进行主动行为。部分消息使用了加密策略，自定义的rsa+des，另外满足我们安全公司的需要，也定制开发很多安全加密策略。一致性是通过冷备解决的，早期考虑双写，但实时状态双写同步代价太高而且容易有脏数据，比如register挂了，调用所有room，通过重新刷入指定register来解决。
Q14:这个keeper有开源打算吗？
还在写，如果没耦合我们系统太多功能，一定会开源的，主要这意味着，我们所有的bind在sdk的库也需要开源~
Q15:比较好奇lisence是哪个如果开源？