接口压力分流

[hack-fang]

目前的接口响应速度较慢

根据最新 https://lab.isaaclin.cn/nCoV/ 接口说明，实现所有的功能，镜像接口 https://lab.ahusmart.com/nCoV/ ，带宽20Mbps，可分担访问压力

[JandenMa]

省市数据的接口是不是挂了？加了province查不出来

[BlankerL]

省市数据的接口是不是挂了？加了province查不出来

正在做数据库的replication，刚才重启了一下数据库，已经正常了。

[BlankerL]

感谢支持，测试通过，功能基本一致。

@hack-fang 针对非API指定关键字，建议在后端过滤，比如 https://lab.ahusmart.com/nCoV/api/area?abc=123 返回结果为最新数据 https://lab.isaaclin.cn/nCoV/api/area?abc=123 返回结果为： {"results": [], "success": false, "msg": "Unrecognized param(s)."}

支持非许可的参数传递，可能有潜在的安全隐患。

同时，目前 https://lab.isaaclin.cn/nCoV/ 数据库已经迁移完成，带宽30Mbps，响应速度应该有比较大的提升。

[JandenMa]

省市数据的接口是不是挂了？加了province查不出来

正在做数据库的replication，刚才重启了一下数据库，已经正常了。

我用postman测试，加了province返回成功，但数组是空的。

[BlankerL]

省市数据的接口是不是挂了？加了province查不出来

正在做数据库的replication，刚才重启了一下数据库，已经正常了。

我用postman测试，加了province返回成功，但数组是空的。

抱歉，没有注意你说的是province数据。

在网页上已经写了，province接口会在2月1日前废弃，建议使用area数据。province数据丁香园已经没有在维护了，这个接口对应的数据我在今天已经和area接口数据合并完成，接口已经停止使用了。

[JandenMa]

省市数据的接口是不是挂了？加了province查不出来

正在做数据库的replication，刚才重启了一下数据库，已经正常了。

我用postman测试，加了province返回成功，但数组是空的。

抱歉，没有注意你说的是province数据。

在网页上已经写了，province接口会在2月1日前废弃，建议使用area数据。province数据丁香园已经没有在维护了，这个接口对应的数据我在今天已经和area接口数据合并完成，接口已经停止使用了。

OK，了解，辛苦了~虽然前后都会搞一搞，但不会爬虫，向您致敬！加油！

[BlankerL]

省市数据的接口是不是挂了？加了province查不出来

正在做数据库的replication，刚才重启了一下数据库，已经正常了。

我用postman测试，加了province返回成功，但数组是空的。

抱歉，没有注意你说的是province数据。 在网页上已经写了，province接口会在2月1日前废弃，建议使用area数据。province数据丁香园已经没有在维护了，这个接口对应的数据我在今天已经和area接口数据合并完成，接口已经停止使用了。

OK，了解，辛苦了~虽然前后都会搞一搞，但不会爬虫，向您致敬！加油！

各有所长～我对这个比较感兴趣😁能出一份力也很开心

[sijiali57]

我之前的其他项目也有过类似问题，数据库云端在AWS，由于经费有限所以CPU和Connection比较小。当时的问题在于大量的Read和Write同时链接数据库，导致反应时间加长，CPUcredit为0。加入replica后，缓解了Read的交通，但是同时需要部署LoadBalancer。不过如果访问量持续增加，这个replica也支撑不了多久。

有一个不成熟的建议，可以不可以把访问量引到GitHub，而不是数据库。比如，做一个API GET class (return overall.csv or area.csv)>> 每小时或每两小时跑一次 >> 数据存储到本GitHub里面“https://github.com/BlankerL/DXY-2019-nCoV-Crawler/tree/master/datasource”. 这样需要一般统计的人，可以直接在这里下载数据。这样API的访问量会减少，GitHub吞吐量完全可以接受下这些访问量。

如果这个方案可行，那么基本可以用下面方法实现（bash + cron）

#!/bin/bash

JOBNAME="Calling Overall Data Started"
echo $MYSTRING

python - << EOF
url ="https://lab.isaaclin.cn/nCoV/api/overall?latest=0"
r = requests.request('GET', url)
data = r.json()
df =pd.DataFrame.from_records(data['results'])
def convertTime(x):
    output=[]
    for i in x:
        a=datetime.datetime.fromtimestamp( i/ 1e3)
        a=a.strftime('%Y%m%d%H%m')
        output.append(a)
    return output
df['dataDate']=convertTime(df['updateTime'])
# save file to your git repo, later could do git push
df.to_csv('overall.csv', encoding='utf_8_sig')

EOF

# push this commit/new file into github
git push -u origin <branch>

echo "Finished uploading overall file to github"

bash file 好了之后，加一个cron job来schedule 什么时候跑这个文件 - 这个方案就是个建议，如果可以，我可以本地试试看

[BlankerL]

我之前的其他项目也有过类似问题，数据库云端在AWS，由于经费有限所以CPU和Connection比较小。当时的问题在于大量的Read和Write同时链接数据库，导致反应时间加长，CPUcredit为0。加入replica后，缓解了Read的交通，但是同时需要部署LoadBalancer。不过如果访问量持续增加，这个replica也支撑不了多久。

有一个不成熟的建议，可以不可以把访问量引到GitHub，而不是数据库。比如，做一个API GET class (return overall.csv or area.csv)>> 每小时或每两小时跑一次 >> 数据存储到本GitHub里面“https://github.com/BlankerL/DXY-2019-nCoV-Crawler/tree/master/datasource”. 这样需要一般统计的人，可以直接在这里下载数据。这样API的访问量会减少，GitHub吞吐量完全可以接受下这些访问量。

如果这个方案可行，那么基本可以用下面方法实现（bash + cron）

#!/bin/bash

JOBNAME="Calling Overall Data Started"
echo $MYSTRING

python - << EOF
url ="https://lab.isaaclin.cn/nCoV/api/overall?latest=0"
r = requests.request('GET', url)
data = r.json()
df =pd.DataFrame.from_records(data['results'])
def convertTime(x):
    output=[]
    for i in x:
        a=datetime.datetime.fromtimestamp( i/ 1e3)
        a=a.strftime('%Y%m%d%H%m')
        output.append(a)
    return output
df['dataDate']=convertTime(df['updateTime'])
# save file to your git repo, later could do git push
df.to_csv('overall.csv', encoding='utf_8_sig')

EOF

# push this commit/new file into github
git push -u origin <branch>

echo "Finished uploading overall file to github"

bash file 好了之后，加一个cron job来schedule 什么时候跑这个文件 - 这个方案就是个建议，如果可以，我可以本地试试看

感谢！我知道有不少项目是用GitHub作为数据仓库，我自己也有private项目用类似方案来储存数据。

目前似乎有不少人做了基于这个API的前端，有一些人的项目会用到API里的新闻内容，而新闻的信息如果做成1-2小时push到数据仓库可能不太友好。如果要这样部署，我可以考虑扩展一下爬虫，将新增内容写入csv文件，并使用cron检查文件的SHA256，如果SHA256发生改变就进行一次推送，时效性可能比较高。

我做这个项目纯粹是出于兴趣，而且也希望能够出一份力，没有想到有这么多人对这个API有需求。目前API使用量较大（API调用量大概在每小时5000次，一天有5-7GB左右的出站流量），而且我每一次对API回传数据进行调整都会收到不少邮件和issue，个人不敢也不太想对API再进行较大的改动了...

由于域名备案问题（我比较懒，现在已经正在备案），无法把服务器部署在大陆的服务器中，导致API的请求一直比较慢。

同时，之前的方案是：数据库部署在阿里云上海的服务器，而网页部署在阿里云香港的服务器（因为都是最基础的服务器，单核单线程，所以不敢开太多任务），因此请求网站后，网页后端和数据库交互的时间会比较长（ping值在50ms以上，而且丢包率大约有10%）。

今天已经将数据库完全迁移到MongoDB Atlas香港节点上，有3份replication并且和后端的延迟在3ms以内，因此晚上12点之后API的访问速度应该有比较明显的提升（和访问人数少也有关系）。明天看一下API在高峰期（大约晚上7点到10点）是否还是如此严重，如果还比较严重，我就改改代码推送到GitHub上，也方便其他做科研的人直接下载数据。

再次感谢如此详细的解决方案！

[guangongka]

老大，接口挂了

[BlankerL]

老大，接口挂了

已经可以正常访问了。不同的问题可以放到不同的issue里。

[cuihuan]

目前的接口响应速度较慢

根据最新 https://lab.isaaclin.cn/nCoV/ 接口说明，实现所有的功能，镜像接口 https://lab.ahusmart.com/nCoV/ ，带宽20Mbps，可分担访问压力

备份接口的数据只有28号之后，可否把之前的数据手工入库一份

[BlankerL]

目前的接口响应速度较慢 根据最新 https://lab.isaaclin.cn/nCoV/ 接口说明，实现所有的功能，镜像接口 https://lab.ahusmart.com/nCoV/ ，带宽20Mbps，可分担访问压力

备份接口的数据只有28号之后，可否把之前的数据手工入库一份

镜像接口的数据可能是不定时从我的API更新的，目前API已经趋于稳定，可以考虑直接调用API。

[BlankerL]

后端已经开启守护进程，应该不会轻易go die了。

数据仓库也已经部署完成，可以访问 https://github.com/BlankerL/DXY-2019-nCoV-Data ，数据每小时自动推送更新。