读写分离与单服务器，哪个好？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› MySQL 5.5 Community Server

› MySQL 5.6 Community Server

› Percona Configuration Wizard

› XtraBackup 搭建主从复制

Great Sites on MySQL

› Percona

› MySQL Performance Blog

› Severalnines

推荐管理工具

› Sequel Pro

› phpMyAdmin

推荐书目

› MySQL Cookbook

MySQL 相关项目

› MariaDB

› Drizzle

参考文档

› http://mysql-python.sourceforge.net/MySQLdb.html

这是一个创建于 1920 天前的主题，其中的信息可能已经有所发展或是发生改变。

假设： 2 台 4 核 8G 的 mysql 云服务器，设置一读一写； 1 台 8 核 16G 的 mysql 云服务器，不读写分离；如何选择比较好呢？请大神指点

MySQL

服务器

分离

指点

14 条回复 • 2019-08-26 15:43:34 +08:00

yrj

2019-08-22 14:23:27 +08:00 via iPad

个人感觉，小站没必要，大站服务拆分是必要过程吧

okwork

2019-08-22 14:26:44 +08:00 via Android

读写比超过 80:20 就分开，不超过就不用分。

taogen

2019-08-22 15:03:11 +08:00 via Android

先搞清楚为什么要读写分离，它的作用是什么

qsbaq

2019-08-22 17:16:59 +08:00

读写分离没毛病，还能当同步备份。
看你需求而定。

opengps

2019-08-22 17:18:57 +08:00

根据业务特征决定：读写分离适用于读写比例明显偏大的场景。比如 v 站，访客多，但是每秒的新帖子和新回复峰值并不高

zjsxwc

2019-08-22 17:28:15 +08:00 via Android

数据库读写分离就是 sql 层面的缓存，是最后的大杀招

因为在应用层面，不管是用 aop 缓存方法调用结果，还是直接拦截代理接口请求缓存，都可以达到类似效果

CallMeReznov

2019-08-22 19:04:54 +08:00

分,一定要分.

s609926202

2019-08-22 19:14:14 +08:00 via iPhone

曾经信了邪，认为两台比一台好

az402

2019-08-22 19:20:58 +08:00 via Android

一台 8u16g 以后扩成两台 8u16g 的成本比两台 4u8g 升级成两台 8u16g 的成本低

dapang1221

2019-08-22 19:35:23 +08:00

首先这个配置就有问题，读写分离是两台机器上都有 mysql 实例，4c8g*2 性能未必比 8c16g*1 高…还得看索引大小，16g 的机器索引存的肯定更多，查询的 io 开销就小，楞拆成俩 8g 没法比

Actrace

2019-08-22 20:25:18 +08:00

单个服务器好。

通常来说数据库本身的缓存机制会处理好读的问题，所以读写分离一般是用于将负载分离到多台物理服务器上。
但是服务器越多，管理成本就越高，所以嘛，为此出现了很多中间件，就是为了解决这个问题。

在我个人看来，数据库的目标是存储和管理数据，因此如果是优化性能，我更建议是放到中间件层面去做，比如用 redis 进行缓存等。

然而大多数公司的业务还不到需要多台物理数据库服务器的程度吧，如果负载太高，请好好从程序层面找一下原因，大部分的问题都是使用不当造成的。

yukiir

2019-08-22 21:06:21 +08:00

我感觉单机好，单机不够了就上缓存，缓存不够了再上读写分离。

areless

2019-08-22 21:12:52 +08:00 via Android

那么你的数据库有 8g 或者 16g 大吗？什么~不够？加内存啊。来来来~shm 放数据，硬盘跑 http 响应，人要学会另辟蹊径

Aresxue

2019-08-26 15:43:34 +08:00

一般情况下当前肯定是单机的快，不过考虑到后续用户量的攀升先做好读写分离也是不错的。
ps：but 大多数系统根本不会有数据量超过系统负荷的那一天，过早优化是万恶之源。