Golang 的 Map 可不可以存大量的数据？比如说几个 GB 的数据

[dw2693734d]

因为 map 是 O(1)的，我想用来当 key value 数据库，快速查询一些数据。

这样会不会有什么隐患问题？

[wurenzhidi]

yes

[koebehshian]

性能不是和算法有关系，和语言有啥关系

[csfreshman]

没问题，我们线上服务器 256G 内存，服务第一次启动加载个 50G 的数据，没问题，后续增量更新。

[phithon]

并发处理好就行

[documentzhangx66]

@ns09005264

健壮的系统，需要的可不仅仅只是简单情况下的性能。

还需要：

1.复杂状况下依然较高的性能。

2.可调试性。

3.可维护性。

4.健壮性。

5.数据安全性、正确性、一致性。

6.整套系统的易用性。

7.整套系统的用法的一致性。

等等。

语言容器直接装数据，那都是上古用法了，在后来漫长岁月的工程实践中，考虑了以上问题，才发展成为专用的数据库，甚至为了保证系统用法的一致性，发明了 SQL 。

[documentzhangx66]

@djoiwhud

“只要不出现雪崩”。

你随便找个交易场景，这样做试试。

然后再猜猜看，为什么要发明数据库。

[documentzhangx66]

@iseki

你说对了。再深挖这个问题，你会收获更多知识。

[documentzhangx66]

@hhjswf

一套系统，就只考虑性能吗？

想想万一程序崩了？

[documentzhangx66]

@PVXLL

在这个话题下，

说说我有什么不懂？

说说你比我懂什么？

[djoiwhud]

@documentzhangx66

您犯了教条主义的问题。任何方案都要看实际需求。不是什么都需要搞一致性可靠性原子性强保证。

有状态服务最普遍的游戏行业大内存缓存是挺普遍的。不是所有业务都是无状态的 http 服务。不是所有业务都要考虑进程挂了怎么办。进程都挂了，还能怎么办？

凉拌。

我说句不好听的话，您要么是偏执的某个领域的资深开发。要么是刚学些皮毛，还处于兴奋期的小白。至于是那种，我没兴趣。

就算你是有千万种教材拿出来说这样子不严谨，你依然不能否定大量公司实际在工程中应用的方案。

[ysc3839]

@documentzhangx66 redis 还要走网络通信，还是基于 TCP 协议的，我认为不会更快。而且许多 redis 客户端库都支持客户端缓存，redis 也支持 value 发生更改时通知客户端清除缓存。

[ysc3839]

@documentzhangx66 我目前就在开发一个支持分布式的服务。客户端会与服务进程通信，服务进程从 redis 获取用户 session 信息，以及上报当前 session 的一些数据到 redis 。还有个管理进程去维护 redis 中的数据，最终数据都是存放在 mysql 中的。
服务进程中有使用 map 进行 redis 数据缓存，曾经实测过每次收到客户端数据时都通过 TCP 连接从 redis 拉取客户端数据，结果是会严重影响性能。而且因为是单 TCP 连接 redis(设计成多连接又会继续增加复杂度)，redis 请求需要类似 HTTP 那样按顺序处理，会导致无法并行处理客户端数据。
所以 map 比 redis 性能好时，为什么还要使用各种类型的数据库呢？因为有别的需求，仅用 map 不能满足这些需求。不能不看需求就认为不能用 map ，而且即使用了 redis ，本地也适合用 map 再增加一层缓存。
比如说上述案例，如果改为全都直接读 SQL 数据库，SQL 数据库没有通知客户端缓存失效的接口。如果管理进程和服务进程通过 RPC 通信来交换数据，那基本等于重新实现了 redis 的功能，又要写很多 RPC 通信的代码，管理进程崩掉也会影响服务进程正常工作，还不如直接使用 redis 。

[mengdodo]

完全没问题，但是要做好各种崩掉的可能性

[daiv]

@csfreshman 启动的时候, 需要几秒, 要不要 30-60s

[documentzhangx66]

@djoiwhud

1.你想通过一堆经验性的东西，来掩饰你之前“只要不出现雪崩”的这句话，毫无意义，还说明了你的业务不值钱。

2.你说这就是你的“大量公司实际在工程中应用的方案”，但你又没说这些大量公司，到底是世界前 500 强，还是那种只有一两个人的皮包公司。500 强的公司数量的确没有皮包公司多。

3.不要总觉得别人是小白，会不会是你的水平不够，看不出别人的水平呢？

我前一条回复你的那句话：为什么要发明数据库。其实就已经点题了，你自己没去深究整个数据库发展史，不去深究你在意的游戏行业，到底是怎么处理这个问题的，以及现有的处理方案，究竟是一种无奈，还是真正的好方案。

4.你回复我之前，但凡认真爬下楼，看看我在前面回复别人的话，也许能让你看懂我的意思，看明白一个系统究竟应该如何取舍，如何设计。从热血传奇、WOW 、EVE 的数据库设计，到 TB 的交易系统设计，难道就不能给你一丁点启发？

[documentzhangx66]

@ysc3839

一个系统，有很多评价指标。性能，不是唯一指标。这个问题，我在前面回复别人时已经说了。

那些只看中性能的中间件，很多年前别人就用 C/CPP 玩烂了，我都不屑于去讨论这个问题。你看看楼上一堆人在讨论 Redis ，几个人提到 Oracle ？

当你的系统，从正规数据库取数据，居然会成为性能瓶颈，那么，你有没有想过，可能是最初的需求，或者最初的系统架构方案，或者是硬件设备选择，出了问题？如果在系统设计时，居然要为了性能，放弃一套成熟系统的其他方面，这套系统是不是有问题？

[ysc3839]

@documentzhangx66 所以你仍然是在不了解他人需求、现状的情况下，就急于否定？就举一个简单的例子，游戏客户端高频低延迟和服务端进行通信，服务端每收到一个包都通过 TCP 从 redis 或其他数据库请求客户端信息，难道不会成为性能瓶颈吗？再者，我只是在 redis 的基础上加上了进程内的缓存，就叫“放弃一套成熟系统的其他方面”？

[documentzhangx66]

@ysc3839

[服务端每收到一个包都通过 TCP 从 redis 或其他数据库请求客户端信息]

无论是 CS Go ，SC 2 、或者王者荣耀，都不会有这种面向辞职式设计。

我建议你先去看看成熟的游戏的网络引擎，到底是怎么通信的。

[djoiwhud]

@documentzhangx66

说个你不爱听的话。我看明白了你压根没什么实际从业经验。再混三五年经验再来反驳我吧。

我是混了十几年开发经验了。我 10 年前，花一两个月每天下班熬夜看 redis 源码的时候，你应该还没写过一行代码。

一个很简单的东西，让你搞，企业没个三五百人的技术团队都不用考虑开工了。

你压根没理解简单的事，简单的处理。还停留在小白学了点皮毛，急不可耐的找机会实践一下炫耀一下，就觉得世界应该那样运行。

基本上所有的游戏业务都是重度依赖内存缓存。实时数据放 redis 的非常非常少。50 帧的同步频率，一毫秒的数据 io 都是不可容忍的。

你真的太幼稚了。还有心思谈业务不值钱。这年头还死磕 battle 那点烂代码值不值钱？行业都什么样了？

信不信你失业了照样一个月没一两次面试机会。

[documentzhangx66]

@djoiwhud

1.你在低端公司，别说混了几十年，就算混了几万年，也就那样了。

我在前面让你去看看一流公司的产品，是怎么设计网络的，看来你是一个字都没看进去。

#
2.你说你熬夜看 redis 源码，这只能说明你不是计算机专业，或者上课根本没听讲，导致基础极差。

基础扎实的人，看看 redis 这玩意的功能特性，就能大致猜中它的运作模式，以及优劣，还用得着去翻源码？

#
3.游戏业务依赖内存？

你可知道游戏也分 RTS 和 WebGame ？那些渣渣 WebGame 用得着重度依赖内存？

所以说，你在低端公司混了几十年，连游戏的分类都搞不清楚。

#
4.50 帧的同步频率，一毫秒的数据 io 都是不可容忍的。你这句话，更是印证了我前面说的，你连游戏的网络设计，毛都不懂。

有空还是去看看人家一流游戏的网络，到底是怎么设计的。

一毫秒都不能容忍，很多玩家吃鸡或 10 人团战时，偶尔高达一两百 ms 的延迟，岂不是得封号处理？

#
5.最后提醒一下，没基础，在行业里混了很多年，这种人不是高手，而是老混子。