CMS 和高流量网站：PHP 和 MySQL
CMS和高流量网站（如新闻门户）在逻辑和数据库设计和优化（PHP和MySQL）方面有什么区别吗？ 我在 stackoverflow 中搜索了 php 站点可扩展性，并且 memcached 占据了大多数。 有没有MySQL优化的技术？ （我正在寻找有关此问题的书。我已在 亚马逊 但我不知道什么是最好的选择。） 提前致谢
Is there any difference between CMS and hight traffic websites (like news portals) in logic and database design and optimization (PHP and MySQL)?
I have searched for php site scalability in stackoverflow and memcached is in a majority.
Is there techniques for MySQL optimization? (Im looking for a book for this issue. I have searched in amazon but I dont know what is the best choise.)
Thanks in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这不太容易回答。
有不同的方法和不同的观点，但我会尽力涵盖一些常见的场景。但首先是一些基础知识。
大多数Web应用程序可以分为应用程序和数据库。
数据库的使用可以分为事务性（oltp）和分析性（olap），
在最好的情况下，您可以启动多个应用程序服务器并在它们之间分配流量。它们都连接到同一数据库服务器并且可以独立工作。
然而，如果您有其他共享数据、会话等，这可能会很困难。
您可以通过简单地将多个 IP 地址添加到 dns 中的域名来实现此目的。
或者您使用负载平衡技术将客户端转发到不同的服务器。
应用程序扩展通常非常容易。数据库要复杂得多。
首先要做的通常是设置一个或多个与主数据库具有相同数据的复制服务器。它们可以级联，但有一个严重的缺点。他们的数据并不总是最新的。一般来说，不会超过几秒钟，但在负载下可能会更多。但对于许多用例来说这很好。
仅显示信息的大型站点可以将其数据库复制到某些从属服务器，设置一些应用程序服务器（最好的做法是在同一台服务器上运行一个从属服务器和一个应用程序服务器，并让该应用程序服务器访问该数据库从属服务器）很好。
每个 olap 查询都可以定向到从属设备。 olap 查询是那些不修改任何内容并且不需要 100% up 2 日期数据的查询。
因此，所有内容都需要写入同一数据库源服务器，所有其他服务器都从该服务器获取其副本。例如一篇文章的每条评论。
如果这个瓶颈变得太紧，你可以朝两个方向发展。
分片意味着您可以决定应用程序服务器在何处存储以及在何处获取数据。
例如每个以 a 开头的评论都会到达服务器 a, b->; b 等等。
这是一个愚蠢的例子，但基本上就是这样。主要涉及一些内部ID。
如果可能的话，最好对数据进行分片，以便可以完全从该服务器中提取数据。
在上面的示例中，如果我想获得一篇文章的所有评论，我必须询问每个服务器 az 并合并结果。这是低效但可行的，因为这些服务器可以被复制。这称为映射（您可以检查著名的谷歌地图缩减算法，它基本上就是这样做的）。
主-主复制意味着您将数据写入不同的主服务器，并且它们相互同步，并且不会像进行分片那样单独存储。
如果您的应用程序无法自行决定在何处存储和获取数据，则必须执行此操作。
您只需存储到任何主服务器，每个服务器都会获得所有内容并且每个人都满意？
不……因为这涉及到另一个严重的问题。
冲突！想象两个用户输入评论。 commentA 存储在 serverA 上，commentB 存储在 serverB 上。我们应该使用哪个 id。哪一个先出现？
最好的方法是设计一个应用程序来避免这种情况并具有不同的键和内容。
但通常发生的是解决冲突、确定优先顺序等等。 oracle在这个级别上有很多功能，而mysql仍然落后。但趋势正在进入更复杂的数据结构，比如云……
好吧，我认为我解释得不好，但你至少应该从文本中得到一些关键字，oyu 可以进一步研究。
this isnt so easy to answer.
there are different approaches and a variety of opinions but ill try to cover some common scenarios. but first some basics.
most web applications can be sperated in application and database.
database usage can be seperated into transactional (oltp) and analytical (olap)
in the best case you can just start a number of application servers and distribute traffic among them. they all have a connection to the same database server and can work independently.
this can be however difficult if you have other shared data, sessions etc.
you can accomplish this by simply adding multiple ip adresses to your domain namen in dns.
or you use load balancing techniques to forward the clients do different servers.
application scaling is generally very easy. database is much more complex.
the first thing to do is usually set up one or more replication servers which have the same data as the main database. they can be cascaded but have 1 serous disadvantage. their data is not always up to date. in general not more than some seconds old but it can be more under load. but for many use cases this is fine.
big sites that just display information could just replicate their database to some slave servers, set up some application servers (its a good practice to run one slave and one application server on the same server and let this application server access this database slave) and every is fine.
every olap query can be directed to a slave. olap querys are those that dont modify anything and dont need 100% up 2 date data.
so everything needs to be written to the very same database source server from which every other server gets its copy. for example every comment for an article.
if this bottleneck gets too tight you can go in two dirctions.
sharding means you decide on the application server where to store and where to fetch your data.
for example every comment that starts with a gets to server a, b-> b and so on.
thats a stupid example but its basically how it is. mostly some internal ids are involved.
if possible its good to shard data so that it can be completely pulled from that server agani.
in the example above, if i wanted to have all comments for an article i would have to ask eveyr server a-z and merge the results. this is inefficitient but possible, because those servers can be replicated. this is called mapping (you could check the famous google map-reduce algorithm whcih basically does just this).
master-master repliation means that you write your data to different master servers and they synchronize each other, and isnt stored seperately like if you do sharding.
this has to be done if your application is not able to decide on its own where to store and fetch data.
you just store to any master server, every server gets everything and everybody is happy?
no... because this involves another serious problem.
conflicts! imagine two users enter a comment. commentA gets stored on serverA, commentB gets stored on serverB. which id should we use. which one comes first?
the best is to design an application that avoids this cases and has different keys and stuff.
but what usually happens is conflict resolving, prioritizing and stuff. oracle has alot of features on this level and mysql is still behind. but trends are going into much more complex data structes like clouds anaway...
well i dont think i explained well but you should at least get some keywords from the text that oyu can investigate further.
当然，您可以采取各种措施来优化高流量网站的 PHP/MySQL Web 应用程序。但是，其中大多数取决于您的具体情况，而您在问题中没有给出具体情况。
无论您是否拥有高流量网站，您的数据库都应该结构良好。如果您使用现成的 CMS，通常就可以了。除了良好的应用程序架构之外，没有一刀切的解决方案。
Sure, there are all sorts of things you can do to optimize your PHP/MySQL web applications for high traffic websites. However, most of them depend on your specific situation, which you haven't given in your question.
Your database should be well structured regardless of whether you have a high-traffic site or not. If you use an off-the-shelf CMS, this is typically fine. Aside from good application architecture, there is no one-size-fits-all solution.