求助：日访问量2000w，如何部署服务器以及数据库？

那要看的东西多了， 要看访问的峰值在什么时候 以及需要压测 以及需要注意数据库

数据库必须要买云数据库，配置要看业务量了，目前4核8G是标配，初期估计够了，随着数据库存储内容的增多，内存占用也会增多，到时候再换 4核 16G，有压力的话随时在主实例下添加一个2核4G的只读，反正这个东东配置可以调整，没必要刚开始就估计过高。买负载均衡的话，多台服务器能节省一些带宽的费用，另外方便突发扩容，也可以容灾，主要是容灾，毕竟是和银行合作。

首先云数据库一定要买的，且是高可用版本，当你的安全防护不到位，数据被清空，可以恢复到前一秒，救你一命。

面对这种不固定的流量，最好采用队列去做一个削峰，同时要做好容量监控，及时增加消费者。

如果有成本方面考虑，可以利用弹性伸缩，固定1-2台按量服务器，然后数台抢占式。出于快速部署考虑，你的业务最好是支持 Docker 镜像方式部署。

访问量两千万 如果数据库操作很少，2核的就够了吧。。我们日pv大概1亿多，4个0.5核pod。2核16g数据库，，，

我认为存储有这么几部分：

敏感信息就放mysql；

一些日志、操作记录，非敏感信息可以放mongodb；

静态资源、用户上传的一些资源可以用对象存储，做个CDN，访问速度也杠杠的；

一些常用数据可以加入redis缓存，减少数据库读取。

如果不涉及到高并发的话，可以用nginx，几台服务器做负载均衡，一两台做好容灾备份。

如果涉及到高并发，这个可能就需要读写分离、分表或者分库了，然后加入队列，如果有条件的话，可以买一个动态扩容啥的，一般来说够用了。

业务简单，按照你说的压力都在fpm上。然后在加上框架问题，fpm就慢。

1、数据库层面 就是云数据库 自带 读写分离的 那种（阿里云应该是有）

2、clb 负载 就得配置自动购买服务器的操作，这个阿里云文档里 都可以配置。

3、4核16g - 8核16g，得有clb自动扩容ecs

4、我们当时遇到这种问题 就是换的java，（如果仅仅是php业务层面比较好改的话，换个swoole类型的框架，常驻服务的那种。）

6、即便你更改fpm的为进程池的模式，连接数还是不够。

综上你考虑吧，问题都在fpm创建子进程、创建连接mysql的开销（代码上能先用redis存储 异步走mysql能加快速度，redis也得考虑用个集群模式的）、以及ecs和mysql机器最大支持连接数都是有上限的，阿里云都有集群模式的云服务。

转发请求及获得的结果需要返回给对方app吗？

云函数

2000wpv fpm下感觉还是不太扛得住 感觉你业务也不是很复杂 换swoole 或者workerman 稳妥一点

云服务的数据库主从一般都很容易配置，除了互为主从需要你从代码上注意自增主键的问题以外，其他都较容易处理。如果公司没有专门运维团队来负责，我还是推荐直接采购RDS产品的，这是云服务商的老本行。如果业务中断或数据丢失造成的损失非常大，建议考虑一下热备，尤其是灾备，这当然需要额外的成本，各团队可量力而为。

如果平时访问量就较大，应考虑一下访问峰值的服务稳定性，这里还是推荐上k8s集群。原因是多点可以尽可能保障服务的稳定性，且容器的自动扩缩能尽可能均衡的耗用各个节点的资源。各个云服务商一般也会支持自动扩缩的节点池，这为计算资源耗尽问题更加一层保障（当然频繁扩缩的费用也不低）。

我的建议是换语言

2000w按照8小时来算，并发没多少啊。不要用RDS，推荐用PolarDB，你会回来感谢我的
我公司目前的项目，几十万在线主播口播时候，最大并发1w+，就是用的阿里云的PolarDB和redis，
sdk服务器也就两台8核16g，按量带宽200m。
最主要的是 我用的是webman框架，laravel肯定是不行的，起码得20台服务器才有可能

2000万pv，平均QPS也才230多，业务主要为查询，如果QPS一天内变化幅度不大的话，数据库一主多从就满足了，至于配置我觉得主库4核8G就完全足够，从库2核4G就可以，至于需要多少业务服务器节点，需要看你单台节点QPS。

你在评论里说：“压力全在php-fpm上面，我们这个请求必须800ms内返回才行，不能使用缓存，写入操作我也已经去掉了，只有查询操作了，数据库是百分百能扛得住的，就php-fpm太多几十个每个都是5%cpu占有率，导致cpu爆满了，难受啊”，业务服务器节点、laraval、php-fpm这些都可以优化的；fpm最为核心的优化就是opcache，剩下参考文档优化下配置，根据单台节点QPS估值来计算业务服务器数量，最后说一点，业务服务器节点不值钱，没必要省那点机器钱。

部署服务器和数据库以支持每日访问量达到 2000 万次（2000w 次）的应用程序需要一定的规划和优化。以下是一些一般性的建议：

1. 服务器集群部署：考虑使用服务器集群以分散流量和提高可用性。您可以配置多个应用服务器和数据库服务器，以平衡负载和提供冗余。使用负载均衡器来分发流量到不同的应用服务器。

2. 性能优化：对服务器进行性能优化，包括合适的硬件配置、操作系统和数据库参数的调整，以确保系统能够处理高负载。使用专业工具进行性能监测和调优。

3. 数据库选择：选择适合高负载应用的数据库管理系统（DBMS）。MySQL、PostgreSQL、MongoDB、Redis等都可以根据应用需求进行考虑。使用数据库集群或复制来提高数据库的可用性和性能。

4. 缓存层：使用缓存来减轻数据库负担。例如，使用 Redis 缓存热门数据，以减少数据库查询。此外，使用 CDN（内容分发网络）来缓存静态资源和加速内容传递。

5. 数据分片：如果可能的话，考虑将数据进行分片存储，以分散数据库负载。分片是将数据分成多个数据库实例，每个实例存储部分数据的方法。

6. 数据备份和恢复：实施定期的数据备份和灾难恢复计划，以确保数据的安全性和可用性。

7. 安全性：实施强大的安全措施，包括防火墙、DDoS 防护、加密、身份验证和权限控制，以保护服务器和数据。

8. 监控和警报：设置监控系统来实时监控服务器和数据库的性能。配置警报以在出现问题时立即通知您的团队。

9. 自动化：使用自动化工具来管理服务器和数据库，包括自动扩展、配置管理和部署流程。

10. 负载测试：在正式上线之前进行负载测试，模拟高负载情况以确保系统可以满足预期的访问量。

11. 云计算：考虑将应用程序和数据库部署在云计算平台上，以便根据需要进行资源的动态伸缩和管理。

12. 容灾计划：制定容灾计划，确保在灾难发生时可以迅速恢复。

部署和管理高访问量的应用程序需要高度的专业知识，因此可能需要与专业的 DevOps 团队或云计算服务提供商合作。此外，根据应用程序的性质，需要灵活地调整架构和资源以满足不断增长的访问量。

所以你的实施方案是怎样的？可以说出来吗

分享一下最后的方案

库里有100个表　热点表有几个表，　单独为这几个表做下优化就行

在这里感谢各位了，我把这个回答设置成最佳答案，用于方便大家看到我最后的解决办法：

1. 首先2000w日活，的话并发前期并不大，但是也是需要考虑后面有别的客户接进来
2. php-fpm 处理并发能力不太行，不推荐大家使用了，太容易超时以及服务挂掉
3. 我一开始使用的是7台，4核8G，服务器扛不住我把它们全部升级成了8核16，还是扛不，又买了3台一共10台，还是扛不住，后面发现使用的第三方包里面解析耗费太长时间了，去掉之后，扛并发能力稍微好一点，但是还是不行达不到理想程度。
4. 最终考虑换框架了，我把接口单独使用一个框架，使用的是easyswoole ，底层是使用swoole框架，最终服务效果达到理想状态，服务器由10台撤掉了6台，为了优化速度，我把云数据库升级成了8核32G，并发连接10000上限。
5. 剩余的4台服务器，我是每台开启300个php的进程，每个进程开始10个Mysql连接
6. 服务器是使用了阿里云的负载均衡，每台服务器是按照流量计费的，云数据库也是按照流量计费的
7. 以上扛住了5000RPS效果。

以上我的处理结果，再次感谢大家们的帮忙，感谢