Transactions in any database are intimidating. It requires a level of understanding beyond just what is stored, but also when it is stored. Unlike the happy world that results when countless layers of abstraction can shield you from complexity, transactions require you to go deeper. Redis is not unusual in this regard. In fact, its entirely different way of thinking about transactions causes a lot of people to say it doesn't have transactions at all. Redis has them, just with an approach that's totally different from the rollbacks you've probably grown up with.
To view transactions at 10,000 ft, you have to understand a few things about Redis. One is that it is single-threaded (well, with a list of exceptions that is perhaps continuing to grow). This means that if it's doing something, that's all it's doing. Of course with Redis, "doing something" is best measured in milli- or nano-seconds. Second, keep in mind that Redis has tunable durability, with some options providing very good durability and some that are totally ephemeral. This obviously has an effect on transactions. Third, it lacks rollbacks but can fail a transaction if a key changes before it starts. This inverted way of controlling transactions lets you pull data back to the client, and evaluate it logically to ensure that the data did not change before the transaction started.