我应该使用全局 ID 还是寻找通知系统的其他解决方案？
所以我几乎已经完成了我的通知系统，就在我即将实施 reCAPTCHA 之前，我测试了如果我发送垃圾邮件通知会发生什么。
向您介绍我的通知系统的一些背景知识。我通过时间戳确定最新内容。我从数据库 ORDER BY 时间戳检索行。时间戳值是一个整数，格式为 Unix 时间。显示通知时，它们是超链接，遵循以下 URL 格式 -
http://test.com/article/id
其中 id 是表的 id，每次提交新文章时，id 都会递增。我注意到在向我的通知发送垃圾邮件后，垃圾邮件通知的 URL 的顺序是相反的。经过进一步调查，我发现如果我发送垃圾邮件的速度足够快，则时间戳变量不够准确，并且会使用相同的时间戳记录多次提交。
由于我的网站现在流量较低，提交的不多，目前这不是问题，但是如果，机会很小，但是如果一条内容与另一条内容同时提交，则通知会排名当它们提交错误时，这是一个小但烦人的错误。
所以我想知道我应该做什么。我应该解决这个问题吗？或者这种情况发生的可能性极小。由于 reCAPTCHA 的实施，垃圾邮件不是问题，但仍有可能意外发生。
我想出了 3 种可能的解决方案。我的问题是哪一个最有效
- 为所有 4 种类型的内容创建一个全局 ID，每次创建评论、文章或更新时该 ID 都会递增。
- 使用更准确的 PHP 时间函数，例如 microtime
- 添加某种二级排名多变的
So I have nearly finished my notification system, and just before I am about to implement reCAPTCHA, I test what happens if I spam the notifications.
To give you some background on my notification system. I determine the newest content, by its timestamp. I retrieve the rows from the database ORDER BY timestamp. The timestamp value is an integer formatted to Unix Time. When notifications are shown, they are hyperlinks, that follow this URL format -
http://test.com/article/id
Where id is the id for the table, each time a new article is submitted, the id increments. I noticed after spamming my notifications, that the URL's of the spammed notifications are in reverse order. After further investigation, I find that if I spam quick enough, the timestamp variable is not accurate enough, and records multiple submissions with the same timestamp.
Since my website is low traffic now, and there aren't many submissions, this is currently not an issue, but if, a very small chance, but if a piece of content is submitted at the same time as another, the notifications will rank when they were submitted wrongly, a small, but annoying bug.
So I'm wondering what I should do. Should I fix the issue, or is this an extremely minute chance of this happening. Due to the implementation of reCAPTCHA, spamming is not an issue, but there is still a chance this could happen by accident.
I have come up with 3 possible solutions. My question is which would be the most efficient
- Create a global id for all 4 types of content, which increments every time a comment, article or update is created.
- Use a more accurate PHP time function, such as microtime
- Add some sort of secondary ranking variable
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
鉴于集群中可能有多个线程甚至多个节点将数据插入不同的表中，因此您使用的任何基于时钟的值总是有可能在多个甚至同一个表中重复。
所以我的第一个想法是使用全局id表。您可以使用一个带有自动递增主键的通用
content表，所有其他表都将其作为外键，并使用该主键进行排序。另一方面，按照同样的逻辑，你能在多大程度上确保提交之间的某种固定顺序？很可能有两个提交会以与服务器接收相反的顺序提交到数据库。我认为解决这个问题的唯一方法是拥有一个所有请求都必须通过的全局看门人。如果您使用这样的网守，那么这也是分配排序值的最佳位置。
总而言之，我认为你不应该坚持完全排序，因为它不存在，除非它是一个高度排序敏感的系统，例如交易或投注。否则，只要对文章发表评论的通知不在文章本身之前出现，微秒就应该足够了。
Given that there can be multiple threads and even multiple nodes in a cluster inserting data in different tables there is always a possibility that any clock based value you use will get duplicated in multiple, or even the same, table.
So my first thought is to use a global id table. You could use a common
contenttable with an auto-incrementing primary key that all other tables foreign key into and use that for ordering.On the other hand, by the same logic, how well can you ensure some fixed order between submissions? It is quite possible that two submissions will be committed to the database in the reverse order of receiving at the server. The only way to solve that problem I think is to a have a global gatekeeper that all requests have to pass through. If you are using such a gatekeeper, that is also the best place to assign the ordering value.
All in all, I think you should not insist on complete ordering because it does not exist unless it is a highly ordering sensitive system such as Trading or Betting. Otherwise microsecond should be good enough, as long as the notification for a comment on a article does not come before the article itself.