一天 2 亿 pv 左右 一般需要多少台机器,目前 swoole+redis+mysql - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
请不要在回答技术问题时复制粘贴 AI 生成的内容
void1900
V2EX    程序员

一天 2 亿 pv 左右 一般需要多少台机器,目前 swoole+redis+mysql

  •  1  
  •   void1900 2019-04-18 11:01:54 +08:00 10410 次点击
    这是一个创建于 2399 天前的主题,其中的信息可能已经有所发展或是发生改变。
    一天 2 亿 pv 左右 一般需要多少台机器,目前 swoole+redis+mysql

    三台机器,其中两台放着 redis+跑 swoole 服务,mysql 是云上的 1H1G 50G...

    目前三台机器负载基本满了,如果换 go 会得到提升吗……

    统计业务,redis 计次,定时+某些条件写入 mysql

    redis
    instantaneous_ops_per_sec:62207
    ...
    80 条回复    2019-04-19 15:53:56 +08:00
    mscb
        1
    mscb  
       2019-04-18 11:03:53 +08:00 via Android
    峰值 qps 有多少呢?
    void1900
        2
    void1900  
    OP
       2019-04-18 11:05:05 +08:00
    @mscb 3000 左右 峰值负载基本上是满的
    void1900
        3
    void1900  
    OP
       2019-04-18 11:06:10 +08:00
    nginx status
    Active connections: 37033
    server accepts handled requests
    31769296193 31769296193 31445439302
    Reading: 2 Writing: 7 Waiting: 37024


    3000 qps 是 ngxtop -l 日志文件的统计
    mscb
        4
    mscb  
       2019-04-18 11:06:30 +08:00 via Android
    我觉得 swoole 已经不错了,直接换到 go 可能不会有大的提升,但是可能还是有帮助。主要是目前瓶颈在哪个方面呢?是数据库部分还是 API 接口部分呢?
    void1900
        5
    void1900  
    OP
       2019-04-18 11:08:40 +08:00
    @mscb 数据库连接数比较低,主要是 redis 和 swoole 的服务, 两台跑 redis+swoole 的机器都分别开了 3 个 redis 实例

    主要是想知道其他语言( java/go )会不会有提升
    sagaxu
        6
    sagaxu  
       2019-04-18 11:08:56 +08:00 via Android
    只是统计?一台就够了
    void1900
        7
    void1900  
    OP
       2019-04-18 11:09:05 +08:00
    三台机器都是 4H8G 的
    Vegetable
        8
    Vegetable  
       2019-04-18 11:09:21 +08:00
    换到的话是可以降低资源的消耗,但是具体能降多少就很难判断了.
    void1900
        9
    void1900  
    OP
       2019-04-18 11:09:57 +08:00
    @sagaxu 统计的维度很多。。。
    mscb
        10
    mscb  
       2019-04-18 11:10:39 +08:00 via Android
    @void1900 那可以试试切换到 go
    sagaxu
        11
    sagaxu  
       2019-04-18 11:10:48 +08:00 via Android
    @void1900 如果统计的 item 不多,直接放内存里,定期刷入 db,redis 都不用
    void1900
        12
    void1900  
    OP
       2019-04-18 11:11:42 +08:00
    @sagaxu 统计的计次维度相乘 大概有 50w 左右,还要 ip,uv 去重,也是放 redis,一台机器不现实吧
    mscb
        13
    mscb  
       2019-04-18 11:12:59 +08:00 via Android
    @void1900 所以看你们的业务,统计还需要做一定的计算是吗?那确实可以试试切换到 go
    void1900
        14
    void1900  
    OP
       2019-04-18 11:14:43 +08:00
    @mscb 计算其实不多,需要的资源确实和业务相关性比较强,算了,太难讨论了,关贴了。。
    davidyanxw
        15
    davidyanxw  
       2019-04-18 11:14:43 +08:00
    一天 pv2 亿,按照 12 小时计算,qps:4629
    两台机器,单机 qps:2314
    qps4000+, 扩容一台机器单机 qps1500+,扩容两台机器单机 qps1200+

    按照 swoole 官方的测试,swoole 的性能比 golang 会高
    https://wiki.swoole.com/wiki/page/508.html

    所以,个人不建议换 golang,收益不会高太多;
    建议扩容,收益更高一些。
    oneonesv
        16
    oneonesv  
       2019-04-18 11:17:49 +08:00
    记得以前压测接口,golang 和 swoole 差距不是很大
    void1900
        17
    void1900  
    OP
       2019-04-18 11:19:02 +08:00
    @davidyanxw 主要 redis 进程 cpu 占用也在 80%左右,我在想 swoole 性能应该是够的
    shenqi
        18
    shenqi  
       2019-04-18 11:21:59 +08:00
    前端外行的建议:

    统计业务入口使用 go 重写,一个入口通过参数,设置不同的统计值+1,写入 redis。实时。
    写入 mysql 那边通过定时或者某些条件触发现有接口写入。非实时。
    F281M6Dh8DXpD1g2
        19
    F281M6Dh8DXpD1g2  
       2019-04-18 11:23:38 +08:00
    你不用换语言就再写一遍性能都会高很多
    void1900
        20
    void1900  
    OP
       2019-04-18 11:23:56 +08:00
    @shenqi 哈哈 现在就是这样了
    void1900
        21
    void1900  
    OP
       2019-04-18 11:28:44 +08:00
    @liprais 感觉瓶颈在 redis,有点太依赖 redis 了,有什么别的方案吗,直接放进程了怕进程重启丢数据比较严重 T_T
    yann1992
        22
    yann1992  
       2019-04-18 11:29:10 +08:00
    换成 Go
    gz911122
        23
    gz911122  
       2019-04-18 11:29:11 +08:00
    借楼插一句
    为什么 php 换语言的话倾向于 go 的比较多呢?
    体感
    jimrok
        24
    jimrok  
       2019-04-18 11:30:25 +08:00
    不用换语言,收效不大。优化你的数据,尽量让热点数据能分散开。cpu 峰值长期不要超过 60%,经常 80%已经明显有风险了。
    dabaibai
        25
    dabaibai  
       2019-04-18 11:30:52 +08:00
    换 go
    void1900
        26
    void1900  
    OP
       2019-04-18 11:31:39 +08:00
    @gz911122
    我猜是因为一般 phper 每个项目人都少,如果

    换 java (会的前提下),人手不够,需要时间太久了
    换 python,性能好像不会得到多大提示
    换 go 开发效率还可以,性能也还可以
    void1900
        27
    void1900  
    OP
       2019-04-18 11:34:41 +08:00
    @jimrok
    确实我也在想这个,现在是按特定次写入数据的。

    但是一些数据少的只能按时写,可是是这部分数据太多了堆积很多,队列会满。

    目前针对一些特定的维度 降低了写入条件,

    是要想下怎么优化这个。 有什么好的方案吗
    hlwjia
        28
    hlwjia  
    PRO
       2019-04-18 11:35:13 +08:00
    换 Go 难道没有成本吗?现在的工程师直接就能写上高质量的 Go 代码?
    sagaxu
        29
    sagaxu  
       2019-04-18 11:35:13 +08:00 via Android
    @void1900 50W 个 key 并不大,累加后定时刷入 redis,重启或者退出前强刷一遍。从 redis 到 db,可以按日刷或者按小时刷。
    mscb
        30
    mscb  
       2019-04-18 11:38:26 +08:00 via Android
    @hlwjia 会 PHP 的人很多也会写 go,如果不会写 go,那楼主就不会考虑 go 语言了
    fcten
        31
    fcten  
       2019-04-18 11:39:54 +08:00
    应该会有一些提升,不过差距不会很大。其实单机能有 3000qps 已经完全可以了,还是加机器吧……
    idblife
        32
    idblife  
       2019-04-18 11:45:20 +08:00
    什么应用有那么高的 pv ?
    这 pv 每天收入得好几万美金了啊。。。
    void1900
        33
    void1900  
    OP
       2019-04-18 11:47:11 +08:00
    @sagaxu

    没法累加 我说的 50w 是统计维度,简单的说下吧:

    假设我要统计 系统+地域+事件的 IP uv pv,那就是:

    系统(假设只有 5 种系统)*地域(假活跃的只有 100 个市)*事件(假设有 50 种)

    5*300*50=75000

    数据报表里是要能看到:不同系统,不同市,不同事件的数据量的,

    意思就是数据库里面每一行会有 三列(系统,市,事件)+三列( IP,UV,PV )

    还有分时和其他统计自动没写,这只是个例子……
    void1900
        34
    void1900  
    OP
       2019-04-18 11:48:10 +08:00
    @fcten 比较想知道 一般正常业务单机 qps 大概是多少,好有个底看优化空间大不大
    blless
        35
    blless  
       2019-04-18 11:51:20 +08:00 via Android
    那个测试 go 1.6 版本… nginx1.4 … php7
    qq976739120
        36
    qq976739120  
       2019-04-18 12:01:01 +08:00   1
    加几台机器一年才多少钱.....成本最低了吧
    void1900
        37
    void1900  
    OP
       2019-04-18 12:15:16 +08:00
    @qq976739120 哈哈哈 确实是成本最低的方法,主要是想挑战一下,还可以提升下自己
    iyaozhen
        38
    iyaozhen  
       2019-04-18 12:19:15 +08:00 via Android
    这个吧,你自己可以线下压测一把吧,看看单机最高能多少。说不定现在翻几倍流量也没事
    laogui
        39
    laogui  
       2019-04-18 12:26:16 +08:00 via Android   1
    每天 2 亿 pv 才三台服务器?这是我见过最牛逼的服务了。这样的用户级别每月收入也有上千万了。
    void1900
        40
    void1900  
    OP
       2019-04-18 12:31:22 +08:00
    @laogui 并没有……
    tiaod
        41
    tiaod  
       2019-04-18 12:32:21 +08:00   3
    2 亿 pv 你来这破站问?
    kevinlm
        42
    kevinlm  
       2019-04-18 12:42:42 +08:00 via iPhone
    什么站,这么强
    jimrok
        43
    jimrok  
       2019-04-18 12:45:56 +08:00
    我觉得你想要减少 redis 的写入量的话,加一套 kafuka,让数据先落盘,然后再用流处理,合并一些统计,减少写入的次数。
    void1900
        44
    void1900  
    OP
       2019-04-18 12:58:18 +08:00
    @jimrok 我研究下,redis 这 ops 确实有点台高! 谢谢大神!
    opengps
        45
    opengps  
       2019-04-18 13:01:00 +08:00
    只看峰值压力,多层服务配合起来( cdn+缓存+负载均衡等等),最终的机器数才能确定出来
    allenhu
        46
    allenhu  
       2019-04-18 13:07:01 +08:00
    加机器吧, 之前的项目,1000w 日 pv 配了 4 台机器
    lsylsy2
        47
    lsylsy2  
       2019-04-18 13:12:11 +08:00
    三台机器,其中两台放着 redis+跑 swoole 服务,mysql 是云上的 1H1G 50G...
    假如 2 亿 PV 还只能养得起这种配置的成本,那要考虑下商业模式了
    agdhole
        48
    agdhole  
       2019-04-18 13:31:48 +08:00
    换 rust 会有提升(成本巨大
    还是加机器 8
    sagaxu
        49
    sagaxu  
       2019-04-18 13:32:33 +08:00 via Android
    @void1900 50w 纬度,不就是 50w 个 key 嘛,每个 key 对应一个 int,每次事件过来,自增几个 int。redis 里能放得下的,进程里面也能放得下。

    这种纯统计的业务,我这边单机可以 10 亿日请求,12 核 32g 内存
    void1900
        50
    void1900  
    OP
       2019-04-18 13:36:26 +08:00
    @sagaxu 什么语言?单进程?
    sagaxu
        51
    sagaxu  
       2019-04-18 13:38:06 +08:00 via Android
    @void1900 JVM + Vertx
    sujin190
        52
    sujin190  
       2019-04-18 14:11:20 +08:00
    看业务复杂度吧,如果只是简单的 redis inc,那么一台都绰绰有余
    一般来说,只是 redis inc,每个请求时间顶多 1ms,一个进程每秒 800 到 900 完全可以吧,swoole 8 核 cpu8 进程不要太轻松
    ethsol
        53
    ethsol  
       2019-04-18 14:22:41 +08:00
    hadoop+spark 怎样
    utfqvfhpyygy
        54
    utfqvfhpyygy  
       2019-04-18 14:35:42 +08:00
    这里全部是动态请求,还是包含了静态资源? 2 亿 一天,3 台机器,而且 4 核 8G 真想看看是什么应用
    loveCoding
        55
    loveCoding  
       2019-04-18 15:09:01 +08:00
    网站发出来看看 , 这么猛的站点
    terranboy
        56
    terranboy  
       2019-04-18 15:24:53 +08:00
    这么多的流量 只舍得 3 台机器吗
    picone
        57
    picone  
       2019-04-18 15:32:03 +08:00
    对实时要求不高,可以加个队列感觉会更好,把波峰削平了。
    而且,这种日志分析的,应该算是离线业务,不应该用 streaming,storm 啥的做吗,前端过来直接全部塞进 kafka 就行了。
    luw2007
        58
    luw2007  
       2019-04-18 15:35:01 +08:00   1
    基于 redis 做 uv 一般是 hyperLogLog。
    建议可以在程序内缓存一分钟数据,然后通过 pipeline 批量导入 redis。
    做好信号处理,监听退出信号,退出前停止接收数据,并强制落盘到 redis。
    压力在 redis 上,换 go 不换逻辑提升不明显。
    atpking
        59
    atpking  
       2019-04-18 15:36:50 +08:00
    我司有个 admqr.com 2 亿没试验过 2kw 的 pv 倒是跑过
    joesonw
        60
    joesonw  
       2019-04-18 15:42:37 +08:00
    瓶颈肯定不在 swoole 这里吧. 看 IO, 和其他的 overhead (例如楼上说的 nginx 那)
    void1900
        61
    void1900  
    OP
       2019-04-18 18:14:06 +08:00
    @luw2007 hyperLogLog 这个很有用之前没看到 感谢感谢!
    sampeng
        62
    sampeng  
       2019-04-18 19:07:06 +08:00 via iPhone
    直接扩容。不要想换语言什么的。机器一年的钱还没你一个月工资多。
    dingyaguang117
        63
    dingyaguang117  
       2019-04-18 19:50:22 +08:00
    redis key 自增 4000QPS 撑不住?好歹也是 C 写的,不太可能吧 建议楼主分析下瓶颈在哪儿
    winglight2016
        64
    winglight2016  
       2019-04-18 20:05:53 +08:00
    换语言不如加机器,或者试试 ELK
    lshero
        65
    lshero  
       2019-04-18 20:13:24 +08:00
    redis 的连接数有多少啊?
    luw2007
        66
    luw2007  
       2019-04-18 20:23:27 +08:00
    @void1900 增加个批量操作。基本 qps 和 cpu 都降下去了,统计业务没必要实时计算。 不丢就行了。
    romeo0
        67
    romeo0  
       2019-04-18 20:26:53 +08:00 via Android
    @sagaxu vertx 稳稳的扛,就是感觉国内知名度太低,招人和找工作多都不方便。
    yufpga
        68
    yufpga  
       2019-04-18 20:54:18 +08:00
    instantaneous_ops_per_sec:62207, 单个 redis 实例这种程度的话,快要跑满了(redis 官方号称 90000-100000,但生产环境复杂,基本达不到的,得看具体的操作)。两台服务器上的 6 个 redis 进程基本上都达到这种程度了么?先确定一下 redis 进程是不是基本上都跑满了,如果 redis 基本上都跑满了,你换什么语言都不管用,直接给 redis 加服吧。
    void1900
        69
    void1900  
    OP
       2019-04-18 21:09:48 +08:00
    @yufpga 这是负载比较高的那台,不过确实 redis 操作有点太频繁,应该有不少优化空间
    rickzuo
        70
    rickzuo  
       2019-04-18 21:10:19 +08:00 via Android
    只有我只关心是什么应用吗-_-||
    yufpga
        71
    yufpga  
       2019-04-18 21:23:30 +08:00
    @void1900 如果是这样的话,尽量让负载均衡一些,打个比方, 比如在城市维度上,让热门城市数据均匀落地,不至于将热门数据集中堆积在某个或某几个 redis 实例上。swool 上的瓶颈和具体业务以及代码有关,没办法给出什么实质建议。
    jorneyr
        72
    jorneyr  
       2019-04-18 21:42:20 +08:00
    中国每天有七分之一的人都在用你的网站服务么,3 台机器支持这么大量的服务,赚了这么多钱就花这么点,不科学。
    codesaler
        73
    codesaler  
       2019-04-19 07:40:10 +08:00
    2 亿 pv 的应用,国内互联网前 500 有吧
    unclemcz
        74
    unclemcz  
       2019-04-19 09:33:29 +08:00
    日均 pv2 亿的服务,不断加服务器就好啦,又不贵。
    keikeizhang
        75
    keikeizhang  
       2019-04-19 09:40:40 +08:00
    喜欢这样的帖子
    tjsdtc
        76
    tjsdtc  
       2019-04-19 09:54:30 +08:00
    @jorneyr 2 亿 pv 不是 uv,不过也已经很可怕了
    tailf
        77
    tailf  
       2019-04-19 09:56:28 +08:00
    两亿 PV 你用了三台机器抗住已经是奇迹了。。。。
    amon
        78
    amon  
       2019-04-19 10:31:39 +08:00
    2 亿 pv,uv 多少呢?
    Seney
        79
    Seney  
       2019-04-19 10:46:02 +08:00
    2 亿 pv, 怎么才能做到??
    lovezww2011
        80
    lovezww2011  
       2019-04-19 15:53:56 +08:00
    换 python 吧,用 django
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     3036 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 33ms UTC 12:50 PVG 20:50 LAX 04:50 JFK 07:50
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86