The iBeacon standard does not provide any built-in ways to prevent cloning. Apple restricts iOS devices from seeing iBeacons except for ones where the ProximityUUID is known, suggesting this may have been a rudimentary security attempt. But since other operating systems (Android, OSX Mavericks, Linux) allow reading identifiers of all iBeacons, this restriction seems rather silly. It is possible to read identifiers using a tool like Android iBeacon Locate and deploy your own iBeacon with the same identifiers.
Four common approaches to address this:
Do nothing. This is appropriate for most use cases where cloned beacons will cause minor consequences or for low profile deployments where the risk of someone doing this is minimal.
Rotate the iBeacon identifiers. You can do this manually by replacing beacons or manually changing their identifiers periodically. This does not eliminate the problem, but it limits the risk and impact on time.
Use an automated rotating identifier combined with an automated system for validating/converting it to a trusted identifier.
Abandon the iBeacon standard and use a proprietary beacon technology using encryption. This should be considered a last resort, because this choice makes it impossible to use widely available open source and commercial tools for working with iBeacons, and locks you into a single vendor.
Before you choose any option other than the first, be sure you carefully evaluate the risk and consequences of cloning, and be sure any countermeasure you take is really worth the downsides.
The multiple notification problem described in the question is generally not an issue in the absence of intentional cloning. Simply design the ProximityUUID/major/minor numbers of your beacons to be unique for each event you wish to give to users and make your app respond appropriately.