用户增长量统计项目实现过程踩坑总结
最近一段时间在做一个用户访问量统计的小项目,主要实现根据打包好的rdb文件进行解析、统计,然后存到pika,然后取到用户key并统计访问量的增长并将数据推到 grafana 进行展示。在代码实现及部署过程中遇到了一些问题,总结出来,以备后续参考。欢迎批评指正,共同学习!
一、在函数中使用多进程正常执行,在类中出现报错
1、导入模块:
import types import copy_reg
2、增加函数
def _pickle_method(m): if m.im_self is None: return getattr, (m.im_class, m.im_func.func_name) else: return getattr, (m.im_self, m.im_func.func_name) copy_reg.pickle(types.MethodType, _pickle_method)
3、在类中增加如下方法
def __init__(self): self.__result = [] def result_collector(self, result): self.__result.append(result)
二、多进程的重复使用
在实现Redis key 的读写采集过程中,在数据采集中用到多进程提高效率,在得到结果往 pika 中存储 key 时,为提高效率,想采用多进程,但测试发现多进程嵌套使用多进程,会出现如下问题 :
Queue objects should only be shared between processes through inheritance
后来考虑到往pika中存数据属于io密集型的操作,因此,采用了多线程,解决了这一问题。这里涉及到多线程如何使主进程等待多个子线程执行完毕,解决方式如下:
t_objs = [] for i in range(100): t = threading.Thread(target=self.batch_send_pika,args=(set_key, redis_port, all_batch_message[i])) t.start() t_objs.append(t) for t in t_objs: t.join() #等待线程的执行结果
三、多进程之间多个Queue实现数据共享
在实现用户读写访问量统计的过程中,由于每条产品线涉及多个端口,每条产品线又有多条规则,为了提高效率,因此对同一条产品线的不同端口采用多进程来实现,要统计同一产品线的用户增长量,就需要对同一规则不同端口之间的数据进行汇总求和,这里就涉及到每条规则启动一个Queue,对不同的端口采集到的数据存到Queue中,然后进行统计。因为要启动多个Queue,还要保证数据和的准确性,这里遇到了一些坑。尝试通过循环拼接字符串启动Queue、尝试过将Queue启动后加入列表作为参数进行传递使用,但是都没有成功,后来通过查资料学习,解决了这一问题。解决方式如下:
from multiprocessing import Queue,Manager q_list = [] for i in range(len(rule_list)): q_name = "q" + str(i) manager = Manager() q_name = manager.Queue() q_list.append(q_name)
然后将q_list作为参数进行传递即可
四、crontab报错
在使用计划任务时未修改成功,遇到如下报错
crontab: installing new crontab
crontab: error while writing new crontab to /var/spool/cron/tmp.XXXXa2LhEO
crontab: edits left in /tmp/crontab.rEpgqL
解决方式如下:
查看磁盘空间和inode节点是否用尽
这里发现/var 目录磁盘空间已经用尽将/var 下无用的文件进行删除,解决了这一问题

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
-
上一篇
企业主流MySQL高可用集群架构三部曲之PXC
前段时间,老张给大家介绍了企业中主流MySQL高可用集群架构三部曲中的前两部,有不了解的同学可以去访问我之前的博客内容。 第一部曲直通车>> 企业中MySQL主流高可用架构实战三部曲之MHA 第二部曲直通车>>企业中MySQL高可用集群架构三部曲之MM+keepalived 独家新课程上线>>MySQL体系结构深入剖析及实战DBA视频课程 今儿给大家介绍最后一部曲,是percona公司的percona xtraDB cluster.简称PXC。它是基于GaLera协议的高可用集群方案。可以实现多个节点间的数据同步复制以及读写,并且可保障数据库的服务高可用及数据强一致性。 PXC 架构图: pxc就属于一套近乎完美的MySQL高可用集群架构方案; 优点总结: 可以达到时时同步,无延迟现象发生 完全兼容MySQL 对于集群中新节点的加入,维护起来很简单 数据的强一致性 不足之处总结: 只支持Innodb存储引擎 存在多节点update更新问题,也就是写放大问题 在线DDL语句,锁表问题 sst针对新节点加入的传输代价过高的问题 实战过程: 环境介绍: 1...
-
下一篇
移动动态化方案在蜂鸟的架构演进(含React Native与Weex对比)
当下,移动动态化已经成为各大公司都回避不了的问题,产品的快速迭代对技术提出了更高的要求,而移动端的动态化方案也是层出不穷:Hypid、结构化 Native View、React Native、Weex,什么样的方案才是适合自己团队的呢?本文将分享饿了么蜂鸟团队在过去两年多业务快速增长过程中,移动动态化方面的实践和探索。 什么是移动动态化? 移动指的是移动端,包括安卓、iOS。动态化则是动态部署和逻辑下发到客户端的能力。移动动态最好的状态就是让移动应用和 Web 一样,想发就发! 为什么移动端要强调动态化的能力? 原因有如下三大点: 业务迭代太快。当下大部分团队都是敏捷开发的模式,即使两周做一次迭代,产品周期还是会觉得长,有些应用不能及时上线。 应用市场审核慢。安卓基本当天发应用市场,当天就能够有更新。但 iOS 需要约 3-4 天来审核。假设有些功能需要定时上线,iOS 审核时间必须要考虑进去。 用户升级周期长。统计表明,每一个安卓版本发布,一周内会有 70% 的用户更新,一个月其余用户才能陆续完成更新。 移动动态化方案共性,有如下三点: 跨平台。 布局。约定 DSL,保证渲...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- MySQL数据库在高并发下的优化方案
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- CentOS8编译安装MySQL8.0.19
- Dcoker安装(在线仓库),最新的服务器搭配容器使用