The resources should only be controlled by the server (securely). How often you update the resources is up to you, your hardware and desired gameplay experience. I don't see why it requires you to update every second but if it does, I am sure it is entirely possible. Besides, some data could be stored in game memory and only updated to database for storage / backup purposes (with constraint validation).

When a user logs in (assuming production continues when offline) you could simply check the last date the user was online and use that to calculate the current amount of cash. The rest of the time, you could let the client can handle the money. When the client makes a transaction, you could check that the current amount of cash corresponds with the constraints. It all depends on the complexity of the game. In general I think you are doing three things that don't necessarily mix well but could work fine depending on your server hw.

1. Update the game state very frequently.
2. Keep all data stored on server side.
3. Run the game as a php app, not a concurrent game server.

Again, I don't see why updating every second should be a huge concern but some benchmarks and tests you could easily perform would alleviate or affirm your suspicions. Then you could lower the rate of updates and/or employ a different strategy (offloading some of the work to client-side [Angular]) or something like that.

tl;dr

The resources should only be controlled by the Server (securely) as a decision making entity; The actual work could be offloaded to Clients and later verified lazily by the Server.

Long story:

How often you update the resources is up to you, your hardware and desired gameplay experience. I don't see why it requires you to update every second? What about every 10 seconds? But if it does, I am sure it is entirely possible with the right hardware. Remember, data that changes frequently could be stored in game memory and only updated to database for storage / backup purposes (with constraint validation).

When a user logs in (assuming production continues when offline), one could simply check the last date the user was online, how much X resource she had and use that to calculate her current amount of resource X. When she plays, let her handle the money, again checking if she is cheating by verifying constraints online. When the client makes a transaction, you could check that the current amount of resource X corresponds with the constraints (what the clients claims matches what the server thinks), calculating the resource state and leaving a tiny buffer for synchronization. 

It all depends on the complexity of the game. In general I think you are doing three things that don't necessarily mix well (if taken to extreme) but could work fine depending on your server HW.

1. Updating game state frequently.
2. Stored all data on a server DB.
3. Run game as HTTP POST/GET requests, not a concurrent game server.

Again, I don't see why updating every second should be a huge concern but some benchmarks and tests you could easily perform would alleviate or affirm your suspicions. Then you could lower the rate of updates and/or employ a different strategy (offloading some of the work to client-side [Angular]) or something like that.