1.carrier数据会有一个group_id

mysql> select * from afrtb_carrier where name like ‘%China mobile%’;
+—–+————–+——-+————+————–+———-+
| id | name | code | country_id | brand | group_id |
+—–+————–+——-+————+————–+———-+
| 255 | China Mobile | 46000 | 45 | China Mobile | 201 |
| 257 | China Mobile | 46002 | 45 | China Mobile | 201 |
| 261 | China Mobile | 46007 | 45 | China Mobile | 201 | 对于以上数据情况，统一个国家下面会有name相同的carrier，因为他们的code不一样，所以这些carrier确实是不同的，这样如果在前端直接显示的话，会出现同一个国家下面有相同name的carrier，所以新增加一个group_id，同一个country下面，name相同的carrier，他们的group_id相同.
在dsp系统中，后端和web的交互完全使用group_id,脚本和rtb的交互则会把group_id转成code

2.给PM做的小工具

这两个工具的代码不再master，在分支liuke_dev上，前端是自己写的，没用到大师他们那些逻辑

前端代码:

后端代码：

1.上传inventory(http://pre3.papayamobile.com:9082/price.html)
功能如下
2.查看campaign的targeting信息(http://pre3.papayamobile.com:9082/monitor_campaign.html)
功能如下:

3.同步脚本部分

以下几个是会加到crontab中执行的任务

1. sync() (scripts/sync_data.py)

同步campaign信息，目前是5分钟执行一次
生成campaign同步信息的过程:
1.排除过期的
2.排除没钱的
3.排除超daily budget的
4.placement budget的控制在xuedong那儿控制 check_campaign_expired() # 根据campaign的start_time和end_time信息判断campaign的status是否应该为STATUS_EXPIRED或者STATUS_ACTIVE real_time_check_account_points() # 根据account快照中的points信息，实时先判断account是否有钱 real_time_check_campaign_daily_budget() # 根据RTB_CAMPAIGN_DAILY_SPEND_KEY判断是否超daily budget

2. sync_account_points() (scripts/sync_data.py)

每天零点同步account的points信息给xuedong，相当于是account的每天的快照，每天只能执行一次

3. rtb_bid_tansfer_points() (scripts/dsp_transfer_old.py)

目前的扣费逻辑，5分钟执行一次，在咱们这边切换扣费表和扣费逻辑完成后，这个脚本就可以停掉了

4. transfer_points() (scripts/dsp_transfer_new.py)

新的扣费逻辑，上线后可以每两分钟执行一次，因为是逐条扣费，所以如果每两分钟的扣费记录比较多的话，这个脚本的扣费时间就会长