有没有童鞋遇到过同样的问题：不使用外键数据完整性到底如何保证十分感谢

Question

问题:不使用外键数据完整性到底如何保证,或者说程序层面如何保证数据完整性?已知的方法:一.使用数据库悲观锁,对相关数据进行锁定,如:select...forupdate形式缺点:操作不当,可能造成死锁二.使用分布式锁,如:redis缺点:主要在于redis锁的不可靠(如:需要设置过期时间,防止死锁.但过期时间太短,可能造成锁失效.主从环境可能造成多个请求同时获取到同一把锁)实际情况中主要是这种情况想不通模拟环境:存在表:角色表:id为整型主键,且自增菜单表:id为整型主键,且自增角色菜单表:id为整型主键,role_id为与角色表id关联的建(不建立外键关系),menu_id为与菜单表id关联的建(不建立外键关系)当向角色菜单表插入数据时,如何确保role_id,menu_id在对应的表都是存在的.当然,我知道,可以在插入之前使用role_id,menu_id在对应的表查一下,确认是否存在.但我看了很多系统都没有做这方面的检查.想不通的地方是这种情况下,根本不需要考虑数据完整性问题吗?(或者说即使存在数据不完整的情况,也可以不在意)?问题点:因为id是自增,如果,被恶意用户,往角色菜单表对特定角色插入了几个未来的menu_id,那么就有可能,造成当那几个未来的menu_id被创建出来之后,那个特定角色就自动获取到了该菜单的权限,而管理员可能根本不知道.不知道我这种表述你们是否明白?

Answer 1

绝大多数情况下，数据稍微有点错误都是可以接受的，一般来说，错误在1%之内都可以接受，基本上不需要锁数据。当然，也有需要严格事务隔离，绝对不能出错的数据，比如财务的数据，这时候最好用数据库的锁或者事务隔离机制去保证。
                            

Answer 2

凡是一致性问题都应根据业务场景来，看你的业务场景是需要强一致性还是最终一致性，8成的业务是可以接受最终一致性的，涉及到钱的就需要强一致性了，当然，实现强一致性就必然会在一定程度上牺牲吞吐量，所以才要根据业务场景来。
ps：你问的我没看懂，我就简单说下一致性的问题……