V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Velocity Beijing 2015
O'Reilly Velocity
Web Performance and Operations
http://velocityconf.com/
YSlow
Best Practices for Speeding Up Your Web Site
xatest
V2EX  ›  Velocity

MySQL数据库异地访问速度优化~

  •  
  •   xatest · 2012-08-13 22:19:34 +08:00 · 3162 次点击
    这是一个创建于 4479 天前的主题,其中的信息可能已经有所发展或是发生改变。
    不清楚这个问题是否适合发在Velocity这个节点,本意是想对数据库服务的访问速度优化。
    我有一个服务,对中国和美国的用户都提供服务,其中美国是主要市场。分别在一台国内的VPS和AWS美国东区节点的EC2上部署相同的服务。之前是没有数据库的服务,最近增加了MySQL数据库设计,需要支持用户在两地都可以快速地访问服务(读写数据)。请教一下要怎么做才能保证两地都可以快速访问?

    先说下我目前想到的几个方案,抛砖引玉:
    1. MySQL在两地都部署,互为主备,进行热备,保持数据一致。好处是两边用户都能很快访问到数据,缺点是这之间的数据同步感觉不可靠,速度也慢,一致性很容易出问题。
    2. 只在AWS美国东部节点部署数据库,中国服务器与美国服务器之间加一台代理(保证传输速度很快),中国的数据操作通过代理透传(就像翻墙)到美国服务器。优点是一致性好解决,缺点是中国用户的访问速度有一点影响。
    32 条回复    1970-01-01 08:00:00 +08:00
    xatest
        1
    xatest  
    OP
       2012-08-13 22:24:42 +08:00
    补充一下现在的几个延时数据。
    我ping中国服务器是150ms;
    我ping美国服务器是400ms;
    美国服务器ping中国服务器430ms;
    美国服务器ping youtube.com 3ms。
    我希望是有种方案能把访问时延控制在200ms以内。
    eric_q
        2
    eric_q  
       2012-08-13 22:29:00 +08:00
    你 ping 中国服务器都能 150ms? 服务器是托管在哪里的...
    KiseXu
        3
    KiseXu  
       2012-08-13 22:48:40 +08:00
    我ping东京的vps才一、二百延迟
    kingwkb
        4
    kingwkb  
       2012-08-13 23:04:50 +08:00   ❤️ 1
    和我们情况差不多,我们把网站及数据库都放ec2,在国内只放个squid或者nginx代理,国内访客解析到国内的代理上面,国外访客直接访问ec2
    xatest
        5
    xatest  
    OP
       2012-08-13 23:14:39 +08:00
    @eric_q 中国服务器托管在西部数码。
    xatest
        6
    xatest  
    OP
       2012-08-13 23:15:36 +08:00
    @KiseXu 我现在的主要问题倒不是选择在哪里部署,而是在已有的2个部署节点上怎么做可以让数据访问更快~
    HowardMei
        7
    HowardMei  
       2012-08-13 23:48:54 +08:00   ❤️ 2
    我早先问过一次同样问题: /t/43356 好久么人解答,研究了一圈,还是觉得这个网络延迟问题很难搞,用Memcached分布式缓存是一条路子,原来感觉好复杂的样子。不过最新发布的MySQL 5.6.6已内置对Memcached支持,据说解决了缓存和数据库不一致的问题,值得试下。
    HowardMei
        8
    HowardMei  
       2012-08-13 23:56:07 +08:00
    @kingwkb 这个好,国内访问性能有影响么?网站动态程度咋样,会不会比较适合静态资源?
    Livid
        9
    Livid  
    MOD
       2012-08-14 05:55:44 +08:00   ❤️ 1
    可以考虑在一个地方部署 DB,然后在 DB 的上层实现 http 的 API,最终让美国和中国的用户访问这个 API,而不是直接访问数据库。
    Livid
        10
    Livid  
    MOD
       2012-08-14 05:56:45 +08:00
    @xatest
    @HowardMei

    这类关于网络服务性能优化的主题非常适合 /go/velocity ,期待能够在 V2EX 见到更多此类话题的讨论。
    ElmerZhang
        11
    ElmerZhang  
       2012-08-14 07:53:49 +08:00
    @HowardMei MySQL 的 Memcached 不是解决楼主这问题的。
    楼主还是把数据库放国外,然后在国内架一个比较快一点的代理好。
    把代理放在离国际出口较近的机房。
    HowardMei
        12
    HowardMei  
       2012-08-14 11:34:28 +08:00   ❤️ 2
    @ElmerZhang 传统Memcached缓存方式对纯动态网站确实没啥改善,可是最新Feature支持直接访问InnoDB,把Mysql当NoSQL用,等于@Livid所说的API,现在没有Benchmarking数据,但理论上,简单K-V省去SQL查询,复杂关系查询可并行SQL,缓存与数据库内生一致,都会大幅提高性能。

    http://dev.mysql.com/tech-resources/articles/nosql-to-mysql-with-memcached.html

    用反向代理缓存页面,让APP和DB服务器处于相同Datacenter,只是避开问题并没有解决问题,我不清楚反代对动态网站性能有多少影响,但不觉得更有优势。
    HowardMei
        13
    HowardMei  
       2012-08-14 11:54:38 +08:00
    直接用Memcached Cluster,不用转成HTTP API,挺好的,就是1MB限制比较那个。
    ElmerZhang
        14
    ElmerZhang  
       2012-08-14 11:57:26 +08:00
    @HowardMei 楼主需要解决的是跨国的网络问题,根本不是数据库内部的数据一致性问题,如果网络没问题,完全可以两个 IDC 做双主。这和什么动态静态用什么数据库没一毛钱关系。
    MySQL 5.6 的 Memcached 插件主要是把协议改为简单的 Memcached 协议,省去 SQL 分析优化等复杂步骤实现更高效的读写,跟缓存神马的关系不大。
    xatest
        15
    xatest  
    OP
       2012-08-14 12:13:49 +08:00
    @kingwkb @ElmerZhang 国内代理有没有推荐?
    zbgzao
        16
    zbgzao  
       2012-08-14 12:19:17 +08:00
    这个问题主要还是国外访问国际网络常会抽风, 这才是最头疼的问题.
    不知你们是什么样的一个场景, 如果实时性不高的话, 那是很好解决的.
    kingwkb
        17
    kingwkb  
       2012-08-14 12:35:07 +08:00
    @xatest
    @HowardMei 我们只是这样规划,网站大概要1个月后上线,1周后会做测试
    coagent
        18
    coagent  
       2012-08-14 13:11:12 +08:00   ❤️ 1
    内容缓存上,Memcached 和反向代理都对性能有帮助。

    HK 到美国的速度比较不错,国内到 HK 速度又很好,可以考虑 HK 和 USA 同步
    eric_q
        19
    eric_q  
       2012-08-14 13:24:03 +08:00   ❤️ 1
    Linode Tokyo
    或者……上海电信
    ElmerZhang
        20
    ElmerZhang  
       2012-08-14 13:48:40 +08:00   ❤️ 1
    @xatest 国内的顶级机房据说都被各大公司抢光了,小公司有钱也买不到机位。
    新浪微博主机房用的北京永丰电信机房,到国外速度还不错,但是网上搜了一下貌似没有这个机房的服务器托管信息。
    @coagent 的方案可以考虑。
    xatest
        21
    xatest  
    OP
       2012-08-14 23:00:52 +08:00
    @zbgzao 目前需求是实时性要求不高,比如访问中国节点写了一些数据,几分钟后能在美国节点读到,就足够了。
    @kingwkb 我们也会在近期实施,到时候我会把后续情况分享给大家。
    @coagent 目前看来先用反向代理比较合适,一步步迭代。谢谢。
    @eric_q @ElmerZhang 谢谢。
    clino
        22
    clino  
       2012-08-15 15:23:13 +08:00   ❤️ 2
    上面 @livid 提到的"在一个地方部署 DB,然后在 DB 的上层实现 http 的 API,最终让美国和中国的用户访问这个 API,而不是直接访问数据库"
    应该就是 openresty 的应用场合之一 http://wdicc.com/intro-openresty/
    clino
        23
    clino  
       2012-08-15 15:34:41 +08:00
    "OpenResty、PHP-fpm与NodeJs操作MySQL的性能对比" http://cnbeta.com/articles/181315.htm
    mikale
        24
    mikale  
       2012-08-17 02:11:08 +08:00
    @clino 最大的问题是数据的不一致性.......
    clino
        25
    clino  
       2012-08-17 15:23:19 +08:00
    @mikale 你是针对我说的吗? 如果是一个地方部署数据库的做法哪里会有不一致性的问题呢?
    kingwkb
        26
    kingwkb  
       2012-08-17 16:00:51 +08:00
    @clino DB上面部属一层API,如果不是有特殊的需求,这样真不前面直接用个代理

    DB上面有加一层API,应该是大公司项目分的很细才能实施和带来好处的,如果是中小公司,这样真心不好。维护成本太高。
    clino
        27
    clino  
       2012-08-17 16:21:22 +08:00
    @kingwkb 用 openresty 来把数据库包装成 http api 好处我想有几个:
    -http 比较通用和简单
    -nginx 本身因为是非阻塞的所以并发能力比较强
    -"已经优化的高效数据库连接池,而一般工程师不用关注连接池的技巧,专心完成业务代码就好,不容易出错"
    这样能做到"就象很高能的网关一样,将后端所有MySQL 服务器的能力都激发出来"

    没用过,但是看着使用起来应该也不会很麻烦的,维护成本应该不会太高
    mikale
        28
    mikale  
       2012-08-17 19:03:53 +08:00
    @clino 网速问题,会造成两边数据不一致..这问题不是通过架构能解决的..
    clino
        29
    clino  
       2012-08-17 22:17:39 +08:00
    @mikale 不太理解你的意思,不知道你说的不一致会有什么表现?
    mikale
        30
    mikale  
       2012-08-17 23:56:36 +08:00
    @clino 主从这东西,如果压力大,内网下延迟都可能达到半个小时...更别说这种网络..

    "美国服务器ping中国服务器430ms;",光ping就延迟..太不理想了,就算压力不大,这种两份数据库的数据差异性,用户会明显感觉出来
    mikale
        31
    mikale  
       2012-08-17 23:57:22 +08:00
    @mikale s/光ping就延迟/ 光ping就延迟这样/g
    clino
        32
    clino  
       2012-08-18 12:16:55 +08:00
    @mikale 汗...我说的部分从来没提到两份数据库啊,童鞋,你回错人了吧
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3566 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 86ms · UTC 05:00 · PVG 13:00 · LAX 21:00 · JFK 00:00
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.